LockFile不能直接替代flock，因语义不同：flock是基于fd的咨询锁，进程退出自动释放；LockFile是基于句柄的强制锁，但Windows默认不启用强制锁，且不随句柄关闭自动释放，还须手动管理偏移区间。
Windows 上 LockFile 为什么不能直接替代 flock
因为语义根本不同：flock 是基于文件描述符的 advisory 锁，进程退出自动释放；LockFile 是基于句柄的 mandatory 锁，但 Windows 默认不启用强制锁机制，且锁不会随句柄关闭自动解除（除非显式调用 UnlockFile 或句柄被系统回收）。更关键的是，LockFile 锁的是文件偏移区间，不是整个文件——哪怕只锁 0 字节，也得自己管理起始和长度，稍不注意就漏锁或重叠。
常见错误现象：LockFile(h, 0, 0, 1, 0) 看似锁首字节，实则锁的是“从偏移 0 开始、长度为 1 的区域”，其他进程仍可对偏移 1 及以后写入；若多个线程共用同一句柄调用 LockFile，还可能触发 ERROR_LOCK_VIOLATION 而不报错（取决于是否设了 OVERLAPPED）。
- 使用场景：仅当需要精确控制某段文件区域、且能确保所有访问方都走同一套锁逻辑时才考虑
LockFile - 参数差异：
LockFile的第 3、4 个参数是低/高 32 位长度，传1表示锁 1 字节，传0xFFFFFFFF, 0xFFFFFFFF才近似全文件锁（但仍有上限） - 兼容性影响：Linux 下
flock支持 fork 后继承，Windows 下句柄默认不继承，需显式设TRUE给bInheritHandle
Linux/macOS 的 flock 在跨平台封装里最常踩的坑
flock 看似简单，但跨平台时三个细节极易翻车：锁类型（LOCK_EX vs LOCK_SH）、阻塞行为（LOCK_NB 必须显式加）、以及 fd 生命周期绑定。尤其在 C++ RAII 封装中，如果析构时没检查 fd 是否有效，flock(fd, LOCK_UN) 可能静默失败，导致下次启动仍被“假锁住”。
常见错误现象：程序崩溃后锁未释放，重启时 flock(fd, LOCK_EX | LOCK_NB) 返回 -1 + errno == EWOULDBLOCK，但开发者误判为“文件正被占用”，实际只是上次残留的 fd 没关干净。
立即学习“C++免费学习笔记（深入）”；
- 使用场景：适合进程级排他控制，如单实例程序、日志轮转、配置文件热更新
- 参数差异：
LOCK_EX和LOCK_SH在 macOS 上行为一致，但在某些旧版 NFS 上LOCK_SH可能不生效，务必测试 - 性能影响：
flock是内核级轻量锁，无系统调用开销激增，但频繁fork后子进程会继承锁，需在子进程中显式close(fd)避免干扰父进程
怎么写一个真正可用的跨平台排他锁 RAII 类
核心思路不是“模拟对方 API”，而是抽象出「获取锁 → 持有期间保证独占 → 释放」三阶段，底层按平台选原生机制。Windows 用 CreateFile + LockFile（锁整个文件），Linux/macOS 用 open + flock，关键在于统一错误处理和资源清理路径。
实操建议：
- 构造函数中打开文件时，Windows 必须设
FILE_SHARE_READ | FILE_SHARE_WRITE，否则其他进程连 open 都失败；Linux 下O_RDONLY即可，flock不依赖读写权限 - 锁操作失败时，统一返回
std::error_code，不要抛异常——跨平台服务常禁用异常，且锁失败应属预期流程 - 析构函数必须调用解锁，且要判断
fd或handle是否合法：Windows 检查handle != INVALID_HANDLE_VALUE，Linux 检查fd >= 0 - 避免用
std::shared_ptr管理锁对象：多个实例共享同一把锁会导致析构时重复 unlock，Windows 下可能触发ERROR_NOT_LOCKED
示例片段（简化）：
// Linux 实现片段
int fd = open(path.c_str(), O_RDONLY);
if (fd == -1) return;
if (flock(fd, LOCK_EX | LOCK_NB) == -1) {
close(fd); // 必须关，否则 fd 泄露
return;
}
// ... 成功持有锁
为什么别碰 fcntl 和 LockFileEx 做跨平台封装
fcntl 的 F_SETLK 在 Linux 上行为接近 flock，但 macOS 对其支持不一致（尤其 NFS）；LockFileEx 支持重叠和超时，看似强大，但它要求文件以 FILE_FLAG_OVERLAPPED 打开，而该标志会禁用 ReadFile/WriteFile 的同步模式——这意味着你得把所有 I/O 改成异步，成本远超锁本身。
更现实的问题是：这两者在交叉编译环境下头文件依赖复杂，fcntl.h 在 MinGW 中可能缺失定义，winbase.h 在非 MSVC 工具链里常需额外宏开关。一旦引入，CI 构建就容易挂。
- 使用场景：仅限已有代码强依赖
fcntl或必须用超时锁的 Windows 专用模块 - 兼容性影响：Android NDK 的 Bionic libc 对
fcntl锁支持有限，iOS 不允许fcntl锁文件描述符 - 容易被忽略的地方：
LockFileEx的超时单位是毫秒，但传 0 表示“立即返回”，传INFINITE才是无限等待——这个和WaitForSingleObject相反，新手极易写反
真要跨平台，老实用 flock 和 LockFile 分支，别贪通用接口。锁逻辑本身不复杂，强行抽象反而让错误路径更难追踪。
