Mutex是Windows下防多开最靠谱的选择，因其为系统级内核对象、跨进程可见、原子性强且支持全局唯一命名，比进程列表检查或临时文件更可靠。
为什么 Mutex 是 Windows 下防多开最靠谱的选择
因为它是系统级内核对象，跨进程可见、原子性强，且能带名字全局唯一。比检查进程列表（Process.GetProcessesByName）或写临时文件更可靠——后者在崩溃残留、权限受限、UAC 提权场景下全会失效。
常见错误现象：Mutex 创建成功却没生效，或者程序退出后锁没释放，导致下次启动卡死。
- 必须用带名字的构造函数：
new Mutex(false, "MyApp.Unique.Name")，不传名字就只是线程内互斥，毫无意义 -
false表示不立即获取所有权，避免初始化时意外阻塞；后续用WaitOne(0)非阻塞尝试获取 - 务必在
finally块里调用ReleaseMutex()，否则锁永远不释放（尤其异常退出时） - 不要在
using语句中直接包裹Mutex——它不是IDisposable的“资源清理型”对象，Dispose()不等于释放所有权
Mutex.WaitOne(0) 返回 false 就代表已被占用
这是判断是否已运行的核心逻辑。很多人误用 WaitOne()（无参）或 WaitOne(1000)，结果程序卡住 1 秒才失败，体验极差。
使用场景：主程序入口（如 Program.Main）第一件事就是尝试抢锁。
static void Main()
{
bool createdNew;
using (var mutex = new Mutex(false, "MyApp.Lock", out createdNew))
{
if (!createdNew)
{
MessageBox.Show("程序已在运行");
return;
}
try
{
Application.Run(new MainForm());
}
finally
{
mutex.ReleaseMutex();
}
}
}
-
WaitOne(0)是关键：0 毫秒超时，立刻返回true（拿到锁）或false（被占） -
out createdNew参数只表示“这个名字的Mutex是否是本次创建的”，不能代替WaitOne判断占用状态 - 如果程序崩溃未走到
finally，系统会自动回收Mutex所有权，所以不用怕永久锁死（这是Mutex的优势）
单实例跨用户/Session 失效？那是没加 Global 前缀
默认 Mutex 在当前 Session 内有效。多用户登录（比如远程桌面、服务账户）时，不同 Session 的同名 Mutex 互不干扰，导致防多开失效。
解决方法很简单：在名字前加 Global 前缀，但要注意权限问题。
- 正确写法：
new Mutex(false, "Global\MyApp.Unique.Name")（注意双反斜杠） - Windows 默认禁止非管理员进程创建 Global 对象，会抛
UnauthorizedAccessException - 绕过方式：改用
Local\前缀（默认行为），或在 manifest 中声明requireAdministrator（不推荐，太重） - 更务实的做法：接受“同一用户 Session 内单实例”，多数桌面应用够用；真需要跨 Session，得配合服务进程或注册表标记
调试时反复启动失败？别忘了关掉“热重载”和调试器残留
Visual Studio 调试时，即使你点了停止，进程可能还在后台挂着（尤其是启用了热重载或 WPF/WinForms 的设计时加载），导致 Mutex 仍被占用。
容易踩的坑：
- 调试中断后没手动结束进程，下次 F5 启动直接失败——去任务管理器看有没有残留的
MyApp.exe - 用
dotnet watch或 Rider 的热重载时，旧进程常不退出，Mutex 不释放 - 测试阶段可临时加日志：
Console.WriteLine($"Mutex created: {createdNew}");，确认到底是谁占了锁 - 发布版没问题，但开发期频繁遇到，说明没清理干净，不是代码逻辑问题
真正麻烦的从来不是怎么写 Mutex，而是怎么让它在各种退出路径下都干净释放——崩溃、Ctrl+C、调试中断、Windows 关机，每种都要想到。
