最直接有效的方式是尝试以generic_read权限和file_share_read|file_share_write标志调用createfile，若返回invalid_handle_value且getlasterror()为error_sharing_violation，则文件被独占占用。
Windows 下用 CreateFile 检测文件是否被独占打开
最直接有效的方式是尝试以不冲突的权限打开文件，看系统是否拒绝。Windows 中，如果一个进程以 FILE_SHARE_READ | FILE_SHARE_WRITE 以外的共享模式打开了文件（比如只共享读、不共享写，或完全不共享），后续调用 CreateFile 就可能失败。
关键不是“查状态”，而是“试打开”——这是唯一可靠的方法，因为操作系统不提供原子性的“当前谁在用”查询接口。
- 用
GENERIC_READ访问权限 +FILE_SHARE_READ | FILE_SHARE_WRITE共享标志去打开；如果返回INVALID_HANDLE_VALUE，且GetLastError()是ERROR_SHARING_VIOLATION，基本可判定文件正被独占占用 - 避免用
GENERIC_WRITE，否则即使文件没被写锁定，仅被其他进程以只读+不共享写打开，也会误报 - 记得调用
CloseHandle()，哪怕打开失败也要确保没资源泄漏（实际只需关成功打开的句柄）
Linux/macOS 下用 open() 配合 O_NONBLOCK 和 O_RDWR
Unix-like 系统没有“独占锁”的默认语义，但很多程序（如数据库、编辑器）会显式加 flock() 或 fcntl() 建议锁。注意：建议锁不强制，只能靠协作；而真正能阻断打开的是某些进程用 O_EXCL 配合 O_CREAT 创建文件时留下的内核级占用，但这不适用于已存在文件。
更实用的做法是尝试非阻塞打开：
- 用
open(path, O_RDWR | O_NONBLOCK)—— 如果返回 -1 且errno == EBUSY或EAGAIN，可能有进程持有独占flock或fcntl写锁 - 但多数情况下，
open()本身不会因他人加了建议锁而失败；所以更常见的检测逻辑是：打开后立刻flock(fd, LOCK_EX | LOCK_NB)，失败则说明已被上锁 -
lsof + grep是调试手段，不能用于生产代码中的实时判断
跨平台封装时别依赖 fstream::is_open() 或 std::filesystem::exists()
这两个函数完全不反映占用状态：exists() 只查路径是否存在；is_open() 只告诉你上次 open() 是否成功，且 C++ 标准库的文件流不暴露底层共享标志或错误码细节。
- 不要写
std::ifstream f("x.txt"); if (f.is_open()) { /* assume free */ }—— 这毫无意义，打开成功只说明你抢到了，不代表之前没人占着，也不代表别人之后不能抢走 - 不要用
std::filesystem::status().type()判断，它连是否可写都不保证，更别说访问冲突 - 若必须跨平台，建议抽象出平台专属的探测函数，统一返回
enum class FileLockState { Free, Busy, Unknown }
容易忽略的边界：临时文件、符号链接、权限不足
检测失败不等于“被独占”，得先排除其他原因。真实场景中，CreateFile 返回 ERROR_ACCESS_DENIED 更常见于权限问题而非占用；open() 返回 EACCES 也可能是 umask 或 ACL 导致。
- 先确认当前进程对路径有读权限（Windows 要
FILE_READ_ATTRIBUTES，Linux 要执行权限进入目录） - 符号链接目标文件被占，但原路径是软链——
CreateFile默认跟随，open()也是，但需留意O_NOFOLLOW行为差异 - 临时文件（如 .tmp 后缀）常被编辑器独占写入，但主文件名可能未锁，此时检测目标文件会误判“空闲”
真正难处理的是“瞬间占用”：你检测完是空闲，fopen() 的一瞬间就被别人抢走。这种竞态无法靠单次检测消除，需要结合重试、锁文件或进程间协调机制。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
