防多开应优先使用全局互斥体（Global前缀、Main方法早创建、不主动Release），进程检测仅用于唤醒提示；需规避会话隔离、调试名混淆、权限异常等常见失效场景。
用 Process.GetProcessesByName 判断进程是否已启动
核心是查系统里有没有同名进程在跑，但要注意“同名”不等于“同程序”——比如都叫 notepad.exe，但可能是用户手动打开的记事本，而非你的程序。所以得结合进程启动路径或主窗口标题进一步确认。
- 先调用
Process.GetProcessesByName("YourApp")，注意传入的是不含扩展名的进程名（如"MyApp"，不是"MyApp.exe"） - 遍历结果，用
process.MainModule.FileName检查路径是否匹配你自己的可执行文件（需捕获AccessDenied异常，某些系统进程会拒绝访问） - 若不想碰权限问题，改用
process.MainWindowTitle+ 窗口类名（GetClassName通过 P/Invoke）辅助判断，更轻量但依赖 UI 线程已初始化 - 别在构造函数或
OnLoad里急着查——WinForms/WPF 启动初期MainWindowHandle可能为 0，建议延后到Shown或SourceInitialized事件中再查
用互斥体（Mutex）防止多开是最可靠的方式
Mutex 是系统级同步原语，跨用户会话也生效（只要没设成 Local 前缀），比查进程名靠谱得多。但它不是“一建就完”，有几个关键点卡住就会失效。
- 创建时必须用全局命名空间，如
new Mutex(false, "Global\{B2C4E678-1234-5678-9ABC-DEF012345678}")，否则默认是会话级，远程桌面或多用户下会重复启动 - 必须在程序最早期创建（推荐
Program.cs的Main方法开头），且创建后立即检查mutex.WaitOne(0)返回值：false 表示已被占用，应直接退出 - 别忘了在主窗体关闭或异常退出前调用
mutex.ReleaseMutex()，否则下次启动会被误判为“已运行”——但实际更稳妥的做法是依赖Mutex的自动释放机制（进程退出时系统回收），所以通常只需WaitOne检查，不主动Release - 如果用了 ClickOnce 部署，版本号变化会导致生成不同应用 ID，互斥体名最好硬编码，别拼接
Assembly.GetExecutingAssembly().FullName
常见错误现象和对应修复
很多“防多开失效”其实不是逻辑错，而是环境或细节没对上。
-
现象：本地测试正常，发布到 Windows Server 上就允许多开
原因：服务端默认启用“快速用户切换”，多个用户登录时互斥体被隔离了；修复：确保互斥体名带Global\前缀，且服务器没禁用全局对象（检查组策略：计算机配置 → 管理模板 → 系统 → 对象 → “启用全局对象”） -
现象：双击快捷方式仍能拉起第二个实例
原因：快捷方式目标写的是MyApp.exe，但实际运行的是MyApp.vshost.exe（调试模式）或 ClickOnce 的Application Files下的副本；修复：统一用最终部署的主程序名创建互斥体，不要依赖开发时的调试名 -
现象：任务管理器里看不到进程，但新实例打不开
原因：旧实例崩溃后没释放互斥体（极少见），或互斥体名被其他程序意外占用；修复：加日志记录互斥体创建/等待结果，临时用Handle工具查系统中是否存在同名Mutex
要不要结合进程检测 + 互斥体？
纯互斥体足够防多开，加进程检测通常是为“友好提示”：比如告诉用户“程序已在运行，是否切换过去？”，而不是直接退出。
- 如果要做“唤醒已有窗口”，得用
SetForegroundWindow+ShowWindow（P/Invoke），但 Win10+ 有焦点限制，需先AllowSetForegroundWindow，否则可能失败 - 别在互斥体失败后才去查进程——顺序反了。应该先尝试获取互斥体，成功则继续启动；失败则立刻查是否有自己进程在跑，有就激活，没有才报错（说明互斥体被第三方占用了）
- 进程检测本身有延迟和权限坑，仅用于 UI 友好性，不能替代互斥体作为防多开主逻辑
互斥体名是否全局唯一、创建时机是否足够早、路径是否匹配真实部署结构——这三个点漏掉任何一个，防多开都会变成玄学。
