必须用 WaitOne(0) 检测锁占用状态，不能仅依赖 createdNew；Mutex 名称需加 Global 前缀才能跨会话，但非管理员下易权限失败；系统自动回收崩溃进程的 Mutex，无需手动释放；Process.GetProcessesByName 存在竞态，不可用于防多开。
直接用 Mutex 就行，但必须配对使用 WaitOne(0) 和正确的命名规则，否则会误判或权限报错。
为什么不能只靠 createdNew 判断是否已运行
很多人写成 new Mutex(true, "MyApp", out createdNew) 然后只看 createdNew 就退出，这是错的。这个参数只表示“这次是不是新创建的互斥体”，不反映当前有没有别的实例正持有它。
比如：第一个实例启动时 createdNew == true；第二个实例启动时，createdNew == false —— 但此时如果第一个实例已经崩溃、没释放锁，第二个实例仍会拿到所有权，createdNew 却还是 false，导致误判为“已有实例在跑”，实际并没有。
正确做法是显式调用 WaitOne(0)：
-
createdNew仅用于初始化判断，不能代替占用状态检测 - 必须紧接着调用
mutex.WaitOne(0)，返回true才代表真正拿到了锁 - 如果
WaitOne(0)返回false，说明锁被占，应退出
Mutex 名称必须带 Global 前缀才能跨用户会话
默认创建的 Mutex 是会话级（Session-scoped）的，同一用户下多个桌面（如远程桌面断开重连）或不同用户登录时，会各自看到一个独立的互斥体，起不到全局防多开作用。
要支持跨会话，名称必须以 Global 开头：
- 正确写法：
new Mutex(false, "Global\MyApp.Unique.Name")（注意双反斜杠） - 错误写法：
"MyApp"或"Local\MyApp"—— 这些都只是当前会话有效 - 权限问题：
Global命名空间在非管理员账户下默认禁止创建，会抛UnauthorizedAccessException - 绕过权限限制的方法：改用
Local前缀 + 启动时检查当前会话 ID，或退而求其次用文件锁
异常退出后互斥体残留？系统会自动回收，不用手动清理
这是常见误解。Windows 内核保证：当拥有互斥体的进程意外终止（如崩溃、被任务管理器杀掉），系统会自动释放该 Mutex，不会永久卡死。
所以你不需要：
- 在
finally里手动ReleaseMutex()（using本身也不释放内核对象） - 写注册表或临时文件来“标记状态”
- 定时轮询检查进程是否存在（竞态条件严重）
但要注意：GC.KeepAlive(mutex) 必须保留，否则 Mutex 对象可能被 GC 提前回收，导致锁提前释放。
别用 Process.GetProcessesByName 做主判断
这段代码看着简单，实际有致命竞态窗口：
var processes = Process.GetProcessesByName("MyApp");<br>if (processes.Length > 1) { /* 退出 */ }两个实例几乎同时执行这行代码，都查到 Length == 0，然后都继续启动 —— 多开就发生了。
Mutex 是操作系统级原子操作，不存在这种时间差。唯一合理用途是辅助显示“正在运行的实例位置”，比如用 Process.MainWindowHandle 激活旧窗口。
复杂点在于：跨会话时，Global 权限和命名冲突是真问题；而多数企业内网场景下，Local + WaitOne(0) 已足够稳定。
