NFSv3及更早版本不支持fcntl强制锁（F_SETLK），且默认禁用NLM，导致加锁失败或跨主机不可见；应改用NFSv4（内建锁支持）并挂载时指定nfsvers=4，避免F_SETLKW阻塞。
Linux下用fcntl加锁时，为什么程序在NFS挂载点上总失败？
因为fcntl的强制锁（F_SETLK）在NFSv3及更早版本上不被支持，且默认挂载时NFS服务器可能禁用nlm（Network Lock Manager）。即使加锁成功，其他主机上的进程也看不到这把锁。
- 优先改用本地文件系统测试，确认逻辑正确
- 若必须走NFS，启用NFSv4（它内建支持
fcntl锁），并确保客户端挂载时带nfsvers=4选项 - 避免依赖
F_WRLCK阻塞等待——NFS下F_SETLKW可能永远挂住，应设超时并用select或poll配合非阻塞轮询 -
flock在NFS上同样不可靠，不要混用
Windows上LockFileEx返回ERROR_IO_PENDING，但没用IOCP就直接等？
这是典型异步模式误用：LockFileEx在文件句柄以FILE_FLAG_OVERLAPPED打开时，才会真正异步；否则即使传入LOCKFILE_EXCLUSIVE_LOCK | LOCKFILE_FAIL_IMMEDIATELY，也会同步执行，ERROR_IO_PENDING根本不会出现。
- 检查
CreateFile是否用了FILE_FLAG_OVERLAPPED——没它，LockFileEx退化为同步调用，返回值是TRUE/FALSE，不是错误码 - 若真要异步，必须配套使用
GetOverlappedResult或IOCP，不能只靠返回值判断成败 - 跨平台封装时，建议统一走同步语义，避免在Windows上强行模拟异步行为，增加心智负担
如何写一个最小可行的跨平台文件锁类，不依赖Boost或std::filesystem？
核心是抽象出「尝试加锁」「释放锁」「自动析构释放」三件事，屏蔽fcntl和LockFileEx的参数差异，同时规避常见陷阱。
class FileLock {
int fd_ = -1; // Linux: open()返回；Windows: _open_osfhandle()
HANDLE handle_ = nullptr;
#ifdef _WIN32
OVERLAPPED ov_ = {};
#else
struct flock fl_ = {};
#endif
<p>public:
explicit FileLock(const char* path) {</p><h1>ifdef _WIN32</h1><pre class='brush:php;toolbar:false;'>handle_ = CreateFileA(path, GENERIC_READ | GENERIC_WRITE,
FILE_SHARE_READ | FILE_SHARE_WRITE, nullptr,
OPEN_EXISTING, FILE_ATTRIBUTE_NORMAL | FILE_FLAG_OVERLAPPED, nullptr);
if (handle_ == INVALID_HANDLE_VALUE) return;else
fd_ = open(path, O_RDWR); if (fd_ == -1) return; fl_.l_type = F_WRLCK; fl_.l_whence = SEEK_SET; fl_.l_start = 0; fl_.l_len = 0; // whole file
endif
}
立即学习“C++免费学习笔记（深入）”；
bool try_lock() {
ifdef _WIN32
return LockFileEx(handle_, LOCKFILE_EXCLUSIVE_LOCK | LOCKFILE_FAIL_IMMEDIATELY,
0, 1, 0, &ov_);else
fl_.l_type = F_WRLCK; return fcntl(fd_, F_SETLK, &fl_) == 0;
endif
}
立即学习“C++免费学习笔记（深入）”；
void unlock() {
ifdef _WIN32
UnlockFileEx(handle_, 0, 1, 0, &ov_);
else
fl_.l_type = F_UNLCK; fcntl(fd_, F_SETLK, &fl_);
endif
}
立即学习“C++免费学习笔记（深入）”；
~FileLock() { if (fd != -1) close(fd); if (handle && handle != INVALID_HANDLEVALUE) CloseHandle(handle); } };
注意：try_lock()必须返回bool，不能抛异常——Windows下LockFileEx失败时GetLastError()才是关键；Linux下fcntl失败时errno才有意义。封装层不处理重试逻辑，由上层决定。
为什么flock和LockFile不能用于跨进程文件锁的可移植方案？
flock是BSD风格的建议性锁，在Linux上不适用于NFS，且glibc对它的实现依赖/proc/self/fd/，容器或chroot环境下可能失效；LockFile是Windows旧API，不支持超时、不支持重叠I/O、无法与LockFileEx共存——同一文件上混用会冲突。
-
flock锁是基于文件描述符的，fork后子进程继承锁，但exec后丢失；而fcntl锁随描述符生命周期，更可控 -
LockFile只能锁整个文件，LockFileEx支持偏移+长度，才能实现“锁某段配置”的细粒度需求 - 跨平台时，宁可多写几行
#ifdef，也不要为了“简洁”选错底层原语
真正的难点不在语法，而在理解每种锁的语义边界：它到底保护什么、谁能看到、失效条件是什么。写完之后，务必在目标环境（含容器、远程挂载、杀进程测试）里验证锁是否真的互斥。
