直接open()失败无法区分“不存在”和“被占用”，因windows依赖共享锁冲突而linux无强制共享机制，errno不可靠；可靠方法是windows用createfilew配file_share_*检测、linux用open(o_path|o_cloexec)试探。
为什么直接 open() 会失败但无法区分“不存在”和“被占用”
在 Windows 上用 fopen() 或 std::fstream 打开一个已打开写入的文件，通常返回失败，但 errno 可能是 ENOENT（文件不存在）或 EACCES（拒绝访问），而后者在 Linux 上往往对应 EBUSY 或 EAGAIN —— 但实际行为因系统、文件系统、打开方式（O_EXCL / O_RDWR）差异极大。单纯靠 errno 判断不可靠。
更关键的是：Windows 的 “文件被占用” 本质是共享锁（share mode）冲突，Linux 则无强制共享锁机制，只有进程级 fd 占用；所以跨平台检测必须绕过“尝试打开”这种副作用强、语义模糊的操作。
- 不要用
std::filesystem::exists()+std::fstream::is_open()组合，它不反映实时占用状态 - 避免用
access()或stat()，它们只检查权限和存在性，不检查是否被其他进程独占打开 - 真正可靠的方式是：尝试以最小权限、非阻塞、不干扰原进程的方式获取文件句柄/描述符
Windows 下用 CreateFileW 配合 FILE_SHARE_* 检测
Windows 要求显式声明共享模式。若文件正被以 FILE_SHARE_NONE 打开（如记事本编辑时），你用任何 dwShareMode 都会失败；若对方用了 FILE_SHARE_WRITE，你用 FILE_SHARE_READ 就可能成功。
实操要点：
- 始终用
GENERIC_READ|GENERIC_WRITE以外的最低权限，例如仅GENERIC_READ -
dwShareMode设为FILE_SHARE_READ|FILE_SHARE_WRITE|FILE_SHARE_DELETE—— 越全越容易成功，但结果也越“宽松” - 必须加
FILE_FLAG_NO_BUFFERING和FILE_FLAG_OPEN_NO_RECALL（可选），避免触发远程文件召回或缓存副作用 - 调用后立即
CloseHandle()，不持有句柄
示例关键片段：
HANDLE h = CreateFileW(
path.c_str(),
GENERIC_READ,
FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE,
nullptr,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL | FILE_FLAG_NO_BUFFERING,
nullptr
);
bool is_free = (h != INVALID_HANDLE_VALUE);
if (h != INVALID_HANDLE_VALUE) CloseHandle(h);
Linux/macOS 下用 open() + O_PATH + O_CLOEXEC
Linux 3.10+ 支持 O_PATH：它不触发 read/write 权限检查，也不受文件锁影响，仅验证路径存在性和基本可访问性，且不会与已有 fd 冲突。这是目前最接近“只读检查”的安全方式。
注意点：
-
O_PATH在 macOS 不可用（需 fallback 到O_RDONLY | O_NONBLOCK+fcntl(F_OFD_GETLK)检查字节范围锁） - 必须搭配
O_CLOEXEC，防止 fork 后泄露 fd - 即使
open()成功，也不能说明文件“空闲”——比如另一个进程正用O_WRONLY打开它，但没加锁；O_PATH仍能成功。所以它只保证“路径可触及”，不是绝对占用判断 - 若需更强保证，可在
O_PATH成功后，用fcntl(fd, F_OFD_GETLK, &lock)尝试申请一个重叠写锁（仅 Linux）
简明判断逻辑：
int fd = open(path.c_str(), O_PATH | O_CLOEXEC); bool is_free = (fd != -1); if (fd != -1) close(fd);
跨平台封装时最容易忽略的三个细节
多数人把 Windows 和 Linux 的判断逻辑并列“或”起来，结果在 NFS、Samba、WSL 等混合环境中误报率飙升。
- Windows 上的
\?UNC...路径和 Linux 的挂载点路径语义不同，统一前先做std::filesystem::canonical()，否则同一文件在不同系统下路径字符串不等价 - 某些杀毒软件或备份工具会在后台对文件加
FILE_SHARE_NONE锁，但不暴露给用户进程 —— 此时你的检测会认为“被占用”，实际用户可正常编辑。这不是 bug，是现实 - 没有真正的“原子性”检测：从你调用到返回之间，文件状态可能已被另一进程改变。所有此类检查都只能反映调用瞬间状态，务必在业务层加 retry 或 timeout 机制
真正健壮的做法不是追求 100% 准确，而是明确告诉调用方：“当前未发现硬性占用，但后续操作仍可能失败”。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
