flock在Windows上根本不可用，因Windows内核无对应实现，直接编译会报undefined reference；跨平台应避免语义差异大的原生锁封装，推荐用std::filesystem::create_directories（原子性）配合原子rename实现无锁互斥，锁路径如"myapp.lock"，临时目录为"myapp.lock.tmp.."，需检查返回值、rename成功才算持锁，退出前必须remove_all清理，否则下次启动可能误判。
flock 在 Windows 上根本不可用
flock 是 Linux/Unix 系统调用，Windows 内核没有对应实现。直接编译带 flock 的 C++ 代码到 Windows 会报 undefined reference to flock 或编译失败。跨平台文件锁不能靠条件编译封装 flock 和 LockFileEx 就完事——语义差异太大。
用 std::filesystem::create_directories + 原子 rename 实现无锁互斥
真正可移植、且避开内核锁机制的思路是：把“加锁”转化为“创建唯一临时目录”，依赖 std::filesystem::create_directories 的原子性（POSIX mkdir + Windows CreateDirectory 都保证“不存在则建，存在则失败”）。再配合 std::filesystem::rename 把临时目录重命名为锁文件名，完成“上锁”信号。
- 锁路径建议用
"myapp.lock"，对应临时目录用"myapp.lock.tmp.<pid>.<timestamp>"</timestamp></pid> - 必须检查
create_directories返回值：false表示目录已存在 → 锁被占用 -
rename成功后才算真正持有锁；失败则需清理临时目录并重试 - 进程退出前务必调用
remove_all删除锁目录，否则下次启动可能误判
Windows 下别碰 LockFileEx，Linux 下别硬套 flock 语义
LockFileEx 锁的是文件句柄，不是文件路径；flock 锁的是 inode，且 fork 后子进程继承锁。两者在“是否可重入”“是否随 close 自动释放”“是否阻塞等待”上行为完全不同。强行桥接会导致死锁或漏锁。
- 如果必须用系统级锁（比如多进程长期共享一个日志文件），Windows 应用
CreateMutexA配合全局命名（如"Global\MyApp_LogMutex"） - Linux 可用
open+O_EXCL | O_CREAT创建锁文件，比flock更易跨平台模拟 - 所有基于文件的锁方案都要处理“进程崩溃未释放锁”的问题，必须带超时检测和 owner PID 校验
推荐方案：用 boost::interprocess::file_lock（但注意链接方式）
boost::interprocess::file_lock 封装了各平台原生机制，语义统一为“对路径加排他锁”，且自动处理 cleanup。但它默认依赖 Boost.System 和 Boost.Thread，在 Windows 上若静态链接 CRT，容易因不同运行时导致 access violation。
立即学习“C++免费学习笔记（深入）”；
- 启用
BOOST_INTERPROCESS_DISABLE_DEFAULT_MUTEX_INITIALIZATION减少初始化风险 - 构建时确保 Boost 和你的项目使用相同 CRT（/MD 或 /MT 一致）
- 锁对象生命周期必须长于所有可能访问文件的操作，不能在作用域末尾就析构
- 它不解决“锁文件残留”问题，仍需配合 pid 文件 + 超时检查
file_lock，没做 owner 检查和心跳更新，照样会在 crash 后卡死。 
