Windows下用CreateMutex检测重复启动最直接，需用GUID命名互斥量、立即获取所有权，并在调用后立刻检查GetLastError()是否为ERROR_ALREADY_EXISTS，否则值可能被覆盖。
Windows 下用 CreateMutex 检测重复启动最直接
Windows 平台最常用、最可靠的单实例方案就是互斥量（Mutex）。核心逻辑是：程序启动时尝试创建一个命名的互斥量，如果创建失败且错误码为 ERROR_ALREADY_EXISTS，说明已有同名实例在运行。
关键点在于名字必须全局唯一且稳定——建议用 GUID 字符串（如 "{A1B2C3D4-5678-90AB-CDEF-1234567890AB}"），避免用可变路径或进程名，否则重装、多用户下容易失效。
示例片段：
HANDLE hMutex = CreateMutex(NULL, TRUE, L"{A1B2C3D4-5678-90AB-CDEF-1234567890AB}");
if (hMutex == NULL) {
// 创建失败，系统错误
} else if (GetLastError() == ERROR_ALREADY_EXISTS) {
// 已有实例，退出当前进程
CloseHandle(hMutex);
return 0;
}
// 否则继续执行主逻辑，记得程序退出前 CloseHandle(hMutex)
注意：CreateMutex 的第二个参数设为 TRUE 表示立即获取所有权，这样能确保后续 GetLastError() 可靠反映“是否已存在”。
立即学习“C++免费学习笔记（深入）”；
Linux/macOS 不能用 CreateMutex，得靠文件锁或 shm_open
POSIX 系统没有命名互斥量概念，常见替代方案是基于文件系统或共享内存。最轻量的是在固定路径（如 /tmp/myapp.lock）上用 flock 加锁：
- 打开文件后调用
flock(fd, LOCK_EX | LOCK_NB)，失败且errno == EWOULDBLOCK表示已被占用 - 文件本身只是锁载体，不存数据，也不需要持久化，程序退出时自动释放（
close即释放） - 务必用绝对路径，避免工作目录影响；同时考虑权限问题，普通用户可能无法写
/var/run/
另一种更健壮但稍重的方式是用 shm_open + sem_open 配合，适合需要跨进程通信的场景，但仅防重复启动的话，flock 足够。
GetLastError() 必须紧跟 CreateMutex 调用，否则值会失效
这是 Windows 编程里最容易踩的坑：一旦中间插入任何可能触发系统 API 的操作（比如 printf、new、甚至另一个 CreateEvent），GetLastError() 就可能被覆盖，导致误判。
正确做法是：
-
CreateMutex后立刻检查返回值和GetLastError() - 不要把判断逻辑拆到另一个函数里，除非你显式保存了错误码
- 调试时加日志没问题，但发布版中所有中间调用都要严格审查
例如下面这段是错的：
HANDLE h = CreateMutex(...);
LOG("mutex created"); // ← 这个 LOG 可能调用了系统 API，改写了 GetLastError
if (GetLastError() == ERROR_ALREADY_EXISTS) { ... } // ← 此时值不可信
单实例不等于“前台激活”，要唤醒旧窗口得额外发消息
互斥量只能告诉你“已经有实例了”，但用户点击图标时，你通常希望把已有窗口带到前台，而不是静默退出。这需要额外步骤：
- 首次启动时，用
FindWindow或记录窗口句柄到共享内存 / 文件 - 重复启动时，通过
SetForegroundWindow+ShowWindow(SW_RESTORE)唤醒 - 注意 Windows 10+ 对后台进程激活有限制，可能需要先
AllowSetForegroundWindow(ASFW_ANY)或配合AttachThreadInput
这部分逻辑和互斥量检测是解耦的——检测归检测，唤醒归唤醒，别混在一起写。
跨平台方案里，Linux 的 WM_CLASS 和 macOS 的 Apple Event 机制也各不相同，统一处理成本高，多数项目只在目标平台做对应唤醒即可。
