\_sopen\_s 返回 error\_sharing\_violation 表明文件正被其他进程以不兼容共享模式独占打开；需同时检查返回值与getlasterror()，优先用createfile配合宽松dwsharemode探测，并避免竞态与调试器干扰。
用 _sopen_s 尝试打开文件时返回 ERROR_SHARING_VIOLATION
这是最直接的信号：目标文件正被另一个进程以不兼容的共享模式打开。Windows 在你调用 _sopen_s 时会检查句柄表和共享锁，一旦冲突就立即失败，不等你读写——所以这不是“打开后才发现”，而是“根本打不开”。
常见错误现象：errno 被设为 EMFILE 或 ENOSPC？不对，此时应是 EACCES（_sopen_s 封装后映射为该值），且 GetLastError() 返回 ERROR_SHARING_VIOLATION（32）。
- 必须同时检查
_sopen_s的返回值 和GetLastError()，只看前者容易误判为权限不足 - 共享模式参数不能瞎写：
_SH_DENYRW表示“我要独占”，但若别人已用_SH_DENYRW打开，你再用它就会撞墙；而_SH_DENYNO表示“我不干涉别人”，成功率最高 - 注意：即使你传了
_SH_DENYNO，如果对方是以CREATE_ALWAYS+FILE_SHARE_NONE创建句柄（比如记事本、Excel 默认行为），你依然会被拒
为什么不用 CreateFile 直接判断更可靠
_sopen_s 是 C 运行时封装，底层仍调 CreateFile，但隐藏了关键控制项。真正决定能否打开的，是 CreateFile 的 dwShareMode 参数和对方持有的句柄属性，_sopen_s 的 shflag 只是它的简化映射。
使用场景：你需要精确区分“文件不存在”、“没权限”、“被独占”这三种失败原因，或者要绕过 CRT 缓存做原子性检查。
- 用
CreateFile时，把dwDesiredAccess设为GENERIC_READ（哪怕只读），dwShareMode设为FILE_SHARE_READ | FILE_SHARE_WRITE—— 这是最宽松的试探方式 - 若返回
INVALID_HANDLE_VALUE且GetLastError() == ERROR_SHARING_VIOLATION，基本可断定被独占 - 别忘了
CloseHandle，哪怕打开失败也要确保没泄漏句柄（某些旧版 CRT 在_sopen_s失败时不会清理内部状态）
跨进程判断的隐含限制：没有 100% 稳定的“瞬间快照”
无论用 _sopen_s 还是 CreateFile，你得到的只是调用那一刹那的状态。文件可能在你拿到句柄后立刻被另一进程锁定，也可能在你检查完、正式打开前就被抢占。
性能 / 兼容性影响：频繁轮询（比如每 10ms 检查一次）会显著增加系统调用开销，并可能触发杀软告警；在 NTFS 上还可能干扰文件系统缓存。
- 不要用“检查 → 等待 → 再检查 → 打开”这种两段式逻辑，中间存在竞态窗口
- 更务实的做法是：直接尝试打开（带合理超时或重试），捕获
ERROR_SHARING_VIOLATION后退避（比如指数退避），而不是先做“空转检查” - 如果业务允许，优先考虑用命名互斥量（
CreateMutex）或文件锁（LockFileEx）与协作方约定，而非被动探测
Visual Studio 调试器下 _sopen_s 行为异常
当程序在 VS 调试器中运行时，某些调试辅助组件（如“仅我的代码”符号加载、内存访问监视）会悄悄对模块所在目录下的 PDB 或日志文件加锁，导致你误以为目标文件被占——其实只是调试器自己干的。
容易踩的坑：GetLastError() 在调试器里可能被中间层覆盖，必须在 _sopen_s 返回后**立刻**获取，不能穿插任何其他 Win32 API 调用。
- Release 模式下复现问题，确认是否真由业务逻辑引起
- 用 Process Explorer 查看目标文件的句柄持有者：搜索文件路径，看哪些进程的句柄列出了它，比猜更准
- 避免在调试时打开同目录下的 .log/.tmp 文件，这些常被 IDE 自动监控
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
