不可靠。fopen("path", "r")在Windows下可能成功但读到脏数据，Linux下更宽松却无法感知写占用；它只检查路径和权限，不保证文件可安全读取，需用CreateFile（Windows）或/proc遍历（Linux）探测写句柄。
用 fopen 尝试以只读方式打开是否可靠？
不可靠。Windows 下即使文件正被其他进程以 FILE_SHARE_WRITE 打开（即允许别人写），fopen("path", "r") 仍可能成功；Linux 下更宽松，默认无强制锁，fopen 几乎总能成功——它只管路径存在、有权限，不管是否被占用。
这导致「能打开」≠「可安全读」，尤其当对方正在写入时，你读到的可能是截断、脏数据或 read 返回 0 的空内容。
实操建议：
- 不要依赖
fopen/std::ifstream构造是否抛异常来判断占用状态 - 若只是想“避免读到一半的写”，需转向系统级文件锁或进程句柄探测
- 跨平台统一方案不存在，必须按 OS 分支处理
Windows 上用 CreateFile 探测写占用最直接
Windows 内核对文件句柄有严格共享控制。用 CreateFile 以 GENERIC_READ + 0 共享模式（即禁止任何共享）尝试打开，失败且 GetLastError() == ERROR_SHARING_VIOLATION，就说明该文件正被至少一个进程以写方式打开（无论是否带 FILE_SHARE_WRITE）。
立即学习“C++免费学习笔记（深入）”；
示例关键逻辑：
HANDLE h = CreateFileA("test.txt",
GENERIC_READ,
0, // 不允许任何共享 → 写占用会直接阻塞
nullptr,
OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL,
nullptr);
if (h == INVALID_HANDLE_VALUE) {
DWORD err = GetLastError();
if (err == ERROR_SHARING_VIOLATION) {
// 被其他进程以写方式打开
}
}
CloseHandle(h);
注意点：
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 必须用
0作dwShareMode，用FILE_SHARE_READ或其它值会绕过检测 - 调用后务必
CloseHandle，否则泄漏句柄 - 此法不区分“只读打开但带
FILE_SHARE_WRITE”和“真实写打开”，只要有人申请了写权限（哪怕没写），就触发ERROR_SHARING_VIOLATION
Linux 上只能靠 open + O_SHLOCK 或遍历 /proc/*/fd
Linux 没有 Windows 那种内建的强制写占用感知。POSIX 文件锁（flock、fcntl）是建议性锁，对方不配合就无效；而 open(..., O_WRONLY | O_NONBLOCK) 即使失败，也不代表文件正被写——可能只是权限不足或路径不存在。
较务实的做法是检查 /proc/*/fd：
- 遍历所有进程的
/proc/PID/fd/目录，读取符号链接目标，匹配你的文件绝对路径 - 再读
/proc/PID/status或/proc/PID/cmdline判断进程用途（可选） - 若发现某个 fd 指向该文件且其
status中CapEff或打开标志含0200000（O_WRONLY等价位），则大概率被写打开
风险提示：
-
/proc方案需要 root 权限才能读取所有进程 fd，普通用户只能看到自己进程 - 符号链接可能指向 hardlink 或 bind mount，路径比对需用
stat()的st_dev+st_ino双重校验 - 没有原子性：检测完瞬间对方就可能关闭文件，仍是竞态
为什么 std::filesystem::exists 和 is_regular_file 完全没用？
它们只查文件元信息是否存在且类型匹配，完全不触碰打开状态。即使文件正被 Excel 锁着写，exists 仍返回 true，is_regular_file 也返回 true——因为文件实体本身没消失。
这类 API 常被误当作“可用性检查”，实际连“能否读”都不保证，更别说“是否被写占用”。真正要防冲突，必须走到系统调用层，且接受 OS 间语义差异。
最容易被忽略的一点：没有银弹。所谓“判断是否被写打开”，本质是在问“此刻有没有人持有可写句柄”，而这个状态在两次系统调用之间就可能变化；所有探测都是快照，业务层必须配套重试、超时或乐观并发策略。
