最可靠方式是Windows下调用CreateFile并设dwShareMode=0，若返回INVALID_HANDLE_VALUE且GetLastError()为ERROR_SHARING_VIOLATION，则文件被独占打开；Linux/macOS需结合lsof和flock判断。
Windows 下用 CreateFile 检测文件是否被独占打开
最可靠的方式是尝试以不兼容的访问模式打开文件——如果失败且错误码为 ERROR_SHARING_VIOLATION，基本可判定该文件正被其他进程以禁止共享的方式打开（比如记事本、Excel、日志写入进程等默认行为）。
关键点在于：必须显式指定 dwShareMode = 0（即不共享读/写），同时使用 GENERIC_READ | GENERIC_WRITE 或至少匹配对方持有的句柄权限。否则即使文件被锁，也可能因共享掩码重叠而成功返回句柄。
-
CreateFile返回INVALID_HANDLE_VALUE时，立即调用GetLastError()判断是否等于ERROR_SHARING_VIOLATION - 不要用
FILE_SHARE_READ | FILE_SHARE_WRITE去“试探”，这会绕过锁定检测 - 某些程序（如 VS Code 编辑器）仅对文件加读锁但允许其他进程读，此时
CreateFile可能成功——需结合具体场景判断“是否影响你的操作”
Linux/macOS 下用 flock 和 lsof 辅助判断
Unix-like 系统没有全局强制独占语义，文件锁分建议性（flock、fcntl）和强制性（需挂载 mand 选项，极少启用），所以无法 100% 确定“被锁”，只能查是否有进程正在读写该文件。
推荐组合手段：
- 运行
lsof +D /path/to/dir或lsof /path/to/file查看哪些进程打开了该文件；注意lsof需要足够权限（如 root）才能看到所有进程 - 用
flock -n /path/to/file -c 'echo ok'尝试非阻塞加锁：失败说明有进程持有（建议性）写锁，但不失败 ≠ 文件空闲 - 检查
/proc/*/fd/目录（Linux）或lsof -p PID（macOS）可定位具体句柄来源，但需知道可疑进程 PID
Python 中跨平台检测的实用边界
别依赖 os.access() 或 os.path.exists()，它们完全不反映锁状态；也别用 open(..., 'r+') 直接抛异常来判断——这在 Windows 上可能触发 UAC 提权弹窗或静默失败，在 Linux 上更不可靠。
真正可用的路径只有：
- Windows：调用
ctypes.windll.kernel32.CreateFileW，参数严格按 Win32 API 要求传（尤其dwShareMode=0） - Linux/macOS：优先用
subprocess.run(['lsof', path], capture_output=True)解析输出，而非尝试加锁 - 所有平台都应设超时（比如 500ms），避免因 NFS 挂起或设备忙导致长时间卡住
常见误判场景和性能陷阱
很多工具把“不能删除”等同于“被锁定”，这是错的——只读属性、目录非空、权限不足、杀毒软件扫描中都会阻止删除，但和进程独占无关。
还有几个容易忽略的点：
- 同一进程多次打开同一文件，若未关闭前一个句柄，后续
CreateFile仍可能失败——不是外部进程，而是你自己代码的问题 - Windows 的“删除重命名”机制（如
MoveFileExwithMOVEFILE_DELAY_UNTIL_REBOOT）会让文件看似“被锁”，实则是系统级延迟操作 - 容器环境（Docker/Podman）中，宿主机
lsof看不到容器内进程打开的文件，需进容器执行；反之亦然
真正的难点从来不在“怎么调 API”，而在区分“谁在用”“为什么用”“能不能等”——这些得结合业务上下文判断，工具只负责给出事实线索。
