Windows下_open()加_O_RDONLY无法打开被独占锁定的文件，因CRT默认共享模式不足；必须用CreateFile()显式设置FILE_SHARE_READ等dwShareMode参数才能绕过锁限制。
用 open() 加 _O_RDONLY 打不开被锁定的文件？不是权限问题，是锁机制在拦你
Windows 下用 _open() 配 _O_RDONLY 试图读一个正被其他进程以独占方式打开的文件（比如 Excel 正在编辑的 .xlsx、记事本没关的 .txt），会直接失败并返回 -1，errno 是 EBUSY 或 EACCES。这不是因为你没加 _O_NOINHERIT 或路径写错了，而是 Windows 文件锁（byte-range lock 或 share mode 冲突）在起作用——只读标志压根不绕过锁。
CreateFile() 的 dwShareMode 才是关键开关
C++ 在 Windows 上真正控制“能否读被占用文件”的，是 Win32 API 的 CreateFile()，尤其它的 dwShareMode 参数。系统级文件锁是否允许你介入，取决于你声明的共享意愿，而不是打开模式（GENERIC_READ 还是 GENERIC_WRITE）。
-
dwShareMode = FILE_SHARE_READ：告诉系统“我只读，允许别人也读或写”——这是最常用且兼容性最好的配置 -
dwShareMode = FILE_SHARE_READ | FILE_SHARE_WRITE：进一步放宽，允许其他进程同时读写（但依然可能被独占锁拒绝） -
dwShareMode = 0：等同于“不共享”，几乎必然失败，除非目标文件根本没被任何进程打开
注意：_open() 等 CRT 封装函数内部也会调用 CreateFile()，但默认传的是 FILE_SHARE_READ；如果它失败了，说明对方是以 FILE_SHARE_NONE 打开的（如 Word、VS 编辑器），这时你必须自己调 CreateFile() 并显式设对 dwShareMode，否则无解。
用 fopen() 或 std::ifstream 基本没戏
这些高级封装完全不暴露共享模式控制权：
-
fopen("locked.txt", "r")底层仍走CreateFile()，但共享模式固定，无法适配被独占锁定的场景 -
std::ifstream f("locked.txt")同样受限，且错误反馈更模糊（f.is_open() == false，不告诉你为什么） - 即使加了
std::ios::in | std::ios::binary，也改变不了共享策略
所以，真要读被锁定的文件，别省那几行代码——老老实实调 CreateFile()，拿到 HANDLE 后再用 _open_osfhandle() 转成 CRT 文件描述符（如果后续要用 read() / fgets()），或者直接用 ReadFile()。
绕过锁 ≠ 绕过数据一致性风险
就算你用 CreateFile() 成功打开了，也要面对现实：
- 对方进程正在写入时，你读到的可能是中间态碎片数据（比如 Excel 保存中途，文件结构不完整）
- 没有原子性保证：读一半时对方删了文件，
ReadFile()可能突然失败，不会自动重试 -
FILE_SHARE_WRITE不代表你能写——你的dwDesiredAccess还是GENERIC_READ，只是“允许别人写”而已
真正安全的做法永远是：先尝试正常打开；失败后检查 GetLastError() 是否为 ERROR_SHARING_VIOLATION；再决定是否降级用 CreateFile() + 宽松 dwShareMode，并做好内容校验（比如解析 JSON 前先 IsValidJson()）。
没人能绕过操作系统级的锁语义，能做的只是更精确地表达你的共享意图。错把 _O_RDONLY 当万能钥匙，才是最常卡住的地方。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
