_fsopen 的 _SH_DENYRW 仅限制跨进程文件访问，同一进程内重复调用仍成功，因其共享模式由 CreateFile 实现且不检查本进程句柄重用；真正进程内互斥需用 std::mutex 或 CreateMutex。
为什么 _fsopen 的 _SH_DENYRW 在 Windows 上不阻止同一进程重复打开？
因为 _fsopen 的共享模式只作用于「不同进程间」的文件访问控制，同一进程内多次调用 _fsopen（哪怕带 _SH_DENYRW）不会报错——它根本不管你自己。这是 Win32 文件句柄层面的设计逻辑，C 运行时只是封装了 CreateFile，而后者默认允许同进程复用句柄。
常见错误现象：_fsopen("data.bin", "rb", _SH_DENYRW) 成功返回后，紧接着再调一次，依然成功；你以为“独占”了，其实只是挡住了其他进程。
- 真正想实现进程内互斥，得自己加
static std::mutex或全局 HANDLE +CreateMutex -
_SH_DENYRW实际等价于CreateFile(..., FILE_SHARE_NONE, ...)，仅影响跨进程共享标志 - 如果用
fopen替代_fsopen，连跨进程保护都没有——它根本不传共享标志
_fsopen 和标准 fopen 在文件锁行为上到底差在哪？
差在是否向系统传递共享标志参数。fopen 完全忽略共享控制，所有打开都等效于 _SH_DENYNO；_fsopen 才把 _SH_* 值转成 CreateFile 的 dwShareMode 参数。
使用场景：只有当你明确需要阻止其他进程（比如另一个 exe 或服务）同时读写该文件时，才必须用 _fsopen + _SH_DENYRW。日常单进程读写、日志追加、配置加载，用 fopen 更轻量且可移植。
立即学习“C++免费学习笔记（深入）”；
-
_fsopen("log.txt", "a+", _SH_DENYRW)→ 其他进程调fopen("log.txt", "r")会失败（errno = EACCES） -
fopen("log.txt", "a+")→ 其他进程无论用什么方式打开，都不会被系统级拒绝 - 注意：
_fsopen是 Microsoft CRT 特有，Linux/macOS 下无对应函数，别写跨平台代码依赖它
用 _SH_DENYRW 却仍被其他程序读到“脏数据”，问题出在哪？
因为 _SH_DENYRW 只管「打开动作」是否被允许，不管「打开后的读写时机」。如果对方进程用的是缓存 I/O（如 fread）、没调 fflush 或 fsync，或者你这边写完没关闭文件句柄，操作系统缓存可能导致数据未落盘，对方读到旧内容——这不是锁的问题，是同步问题。
性能影响：启用 _SH_DENYRW 不影响本进程性能，但会增加其他进程打开文件时的失败概率和等待开销（尤其在高并发文件访问场景）。
- 写入后务必调
fflush(fp)+_commit(_fileno(fp))（Windows）确保落盘 - 读取方也应避免只靠 fopen/fread，需检查
stat()修改时间或用ReadFile配合FILE_FLAG_NO_BUFFERING（极端情况） - 不要以为加了
_SH_DENYRW就能跳过应用层同步逻辑，它不是事务锁
替代方案：比 _fsopen + _SH_DENYRW 更可靠的独占控制怎么做？
靠运行时函数做独占太弱，真要强约束，得下到 Win32 层或引入额外机制。C++17 的 std::filesystem 也不提供文件锁接口，所以绕不开平台 API。
- 用
CreateFile显式指定CREATE_NEW标志创建新文件，失败即说明已被占用（适合初始化场景） - 打开后立刻调
LockFileEx对整个文件加排它锁（LOCKFILE_EXCLUSIVE_LOCK），支持重入和超时 - 更轻量的方案：用
CreateMutex命名互斥体（如L"Global\MyApp_DataLock"），进程间协调成本低且稳定 - 注意：
LockFileEx锁的是字节范围，不是文件名；关掉句柄自动释放，但进程崩溃可能残留，需配合超时或心跳检测
最常被忽略的一点：_SH_DENYRW 不防程序崩溃后残留句柄，也不防断电丢数据。真正的独占从来不是单靠一个参数，而是打开、操作、校验、清理这一整套动作的配合。
