最可靠单实例控制方式是用CreateMutex创建命名互斥量并检查GetLastError()是否为ERROR_ALREADY_EXISTS；句柄非NULL不代表失败，必须据此判断是否已有实例；命名需全局唯一（推荐Global+GUID），std::mutex无法跨进程，退出时仅首个实例需CloseHandle。
用 CreateMutex 检测命名互斥量是否已存在
Windows 下最直接、最可靠的单实例控制方式，就是创建一个命名互斥量（CreateMutex），并检查返回值和 GetLastError()。如果互斥量名已被占用，CreateMutex 会返回有效句柄，但 GetLastError() 返回 ERROR_ALREADY_EXISTS —— 这就是“已有实例在运行”的铁证。
关键点不是“创建失败”，而是“创建成功但已存在”。很多人误判 NULL 返回才代表失败，其实只要句柄非 NULL 就说明对象存在（无论新建还是打开），必须紧接着调用 GetLastError() 才能区分。
常见错误写法：
HANDLE hMutex = CreateMutex(NULL, FALSE, _T("MyApp_SingleInstance"));
if (hMutex == NULL) { /* 错！这里只捕获系统级失败，漏掉已存在场景 */ }正确做法应是：
立即学习“C++免费学习笔记（深入）”；
- 始终检查
hMutex != NULL，否则跳过后续逻辑 - 立即调用
GetLastError()，对比是否等于ERROR_ALREADY_EXISTS - 若等于，说明已有实例，当前进程应退出（注意：不要 CloseHandle）
- 若不等于，说明是新创建的，当前进程可继续运行；退出前务必
CloseHandle(hMutex)
命名互斥量的名字必须全局唯一且稳定
名字不是随便起的字符串，它本质是 Windows 内核对象路径的一部分，受命名空间限制。比如 "MyApp" 太短，容易与其他程序冲突；"Local\MyApp" 和 "Global\MyApp" 行为也不同 —— 前者仅限同一会话（Session），后者跨所有会话（如服务与用户桌面之间）。
推荐使用带公司/产品标识的完整名称，例如："Global\{A1B2C3D4-5678-90AB-CDEF-1234567890AB}"（GUID 格式）或 "Local\CompanyName.ProductName.v1"。避免纯数字、空格、反斜杠、非法字符。
容易踩的坑：
- 调试时反复运行，旧互斥量可能残留（尤其异常退出未
CloseHandle）→ 导致后续启动总被拒 - UAC 提权后进程运行在不同 Session，用
Local\前缀会导致两个实例共存（一个普通用户，一个管理员）→ 必须用Global\或显式处理 Session 隔离 - 名字大小写敏感？不敏感，但建议统一小写避免混淆
std::mutex 不能用于进程间单实例控制
std::mutex 是 C++ 标准库提供的线程级同步原语，它只在**单个进程内有效**，底层通常包装的是临界区（CRITICAL_SECTION）或轻量级内核对象。它无法跨进程识别或共享，所以完全不能用来防止“多开”。
如果你在 main() 开头写了：
std::mutex g_instance_mutex; g_instance_mutex.lock(); // ❌ 这只能锁住当前进程内的线程，对其他进程毫无影响
那只是白忙一场。真正需要的是 Windows 内核对象（Mutex、Event、Semaphore），它们由系统维护、支持命名、跨进程可见。
补充说明：
-
std::mutex+std::lock_guard适合保护本进程内多个线程对共享变量的访问 - 单实例检测属于进程间通信（IPC）范畴，必须用 Win32 API 的命名对象
- 不要试图把
std::mutex句柄传给DuplicateHandle——它根本不是内核句柄
退出时必须 CloseHandle，但别在检测到已存在时关
句柄泄漏不是小问题：每个未关闭的命名互斥量都会持续占用系统资源，直到所有持有它的进程退出。如果主程序崩溃或忘记 CloseHandle，这个互斥量可能残留数小时甚至更久，导致用户重启后仍无法启动。
正确释放时机：
- 当
CreateMutex成功且GetLastError() != ERROR_ALREADY_EXISTS→ 当前进程是首个实例，应在程序退出前（比如main结束前或ExitProcess前）调用CloseHandle(hMutex) - 当检测到
ERROR_ALREADY_EXISTS→ 当前进程不是所有者，不应调用CloseHandle（否则可能提前释放掉别人正在用的互斥量） - 如果用了
bInitialOwner = TRUE，记得在释放前确保已ReleaseMutex，否则其他进程永远等不到信号
最稳妥的做法是把互斥量句柄封装进 RAII 类（比如 ScopedMutexHandle），构造时创建，析构时自动 CloseHandle，但需加标志位区分是否“自己创建的”。
复杂点在于：互斥量生命周期必须严格匹配主实例生命周期，稍有疏忽就会让“防多开”变成“永久锁死”。
