最直接有效的方式是调用CreateFile以dwShareMode=0尝试独占打开，若返回INVALID_HANDLE_VALUE且GetLastError()为ERROR_SHARING_VIOLATION，则文件被其他进程以不兼容共享模式锁定。
Windows下用CreateFile判断文件是否被其他进程锁定
最直接有效的方式是尝试以独占方式打开文件，CreateFile 的返回值和 GetLastError() 能明确告诉你是否被占用。这不是“探测”，而是真实尝试获取句柄——操作系统内核会做最终仲裁。
关键点在于：必须指定 dwShareMode = 0（不共享读/写/删除），且 dwDesiredAccess 至少包含 GENERIC_READ 或 GENERIC_WRITE；否则即使文件被锁，也可能成功打开。
- 成功返回非
INVALID_HANDLE_VALUE→ 文件当前未被独占锁定（但不保证后续操作安全） - 失败且
GetLastError() == ERROR_SHARING_VIOLATION→ 明确表示被其他进程以不兼容共享模式打开 - 失败且
GetLastError() == ERROR_ACCESS_DENIED→ 可能是权限问题，也可能是被以FILE_SHARE_NONE打开后还加了读写锁（如记事本编辑中） - 不要用
FILE_ATTRIBUTE_NORMAL或GetFileAttributes判断——它们完全不涉及句柄竞争，毫无意义
Linux/macOS下用open + O_EXCL 和 O_RDWR 组合不可行？
O_EXCL 在 open() 中只对 新建文件 有效，对已存在文件加锁无效——这是常见误解。Linux 没有“打开即锁定”的原语，得靠 flock() 或 fcntl()。
实际可行路径只有一条：用 open() 以 O_RDWR 打开，再立即调用 flock(fd, LOCK_EX | LOCK_NB) 尝试加建议性写锁。
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
立即学习“C++免费学习笔记（深入）”；
- 成功 → 当前进程可认为“逻辑上”获得排他访问权（注意：仅建议锁，依赖所有参与者遵守）
- 失败且
errno == EWOULDBLOCK→ 已被其他进程持有了LOCK_EX或LOCK_SH（取决于对方锁类型） - 不要用
access()或stat()——它们返回存在 ≠ 可读写 ≠ 未被锁 - 注意：NFS 等网络文件系统可能不支持
flock，此时需降级为检查/proc/*/fd（Linux）或改用lsof外部命令（不推荐自动化场景）
跨平台代码里别碰 fstream::is_open() 或 ifstream::fail()
这些方法只反映 C++ 流对象自身的状态，完全不体现底层文件是否被 OS 锁定。比如在 Windows 上用 std::ofstream 打开一个被 Excel 占用的 .xlsx 文件，is_open() 很可能返回 true（因为 ofstream 默认以共享模式打开），但后续 write() 会静默失败或写入零字节。
-
std::fstream构造或open()不抛异常也不报告共享冲突，除非你显式设置std::ios_base::failbit并检查 - 真正可靠的判断必须下沉到系统 API 层：Windows 用
CreateFile，POSIX 用open + flock - 如果必须用 C++ 标准库封装，至少在 open 后立刻
flush()并检查bad()，但这只能捕获部分错误，不能替代系统级检测
为什么“检查进程列表”不是正解
有人想解析 lsof 输出或遍历 /proc/*/fd 查找目标文件路径，这看似直观，实则问题极多：
- 路径可能被
openat()+ 相对路径打开，proc 中显示的是解析后的绝对路径，比对易错 - 多个硬链接指向同一 inode，但路径字符串不同，简单字符串匹配失效
- 容器环境、chroot、user namespace 下
/proc视图受限，甚至不可见 - Windows 上没有等价稳定接口；WMI 查询
CIM_DataFile性能差且常超时，Handle.exe是外部工具，无法嵌入生产逻辑
真正需要鲁棒性时，唯一靠谱的做法就是“尝试获取资源”，而不是“猜测谁拿了它”。文件锁的本质是同步原语，不是状态快照。
