FileStream尝试打开是最可靠检测方式，因Windows无公开API直接查询文件锁状态，需以相同FileShare模式模拟访问：成功则未占用，抛出含HResult=-2147024864或“正由另一进程使用”的IOException则被独占。
用 FileStream 尝试打开文件是最可靠的检测方式
Windows 没有公开的 API 能直接查询“某文件当前是否被其他进程独占”，File.Exists 或 File.GetAttributes 都无法反映锁状态。唯一可信赖的做法是模拟真实访问：用 FileStream 以你后续要使用的相同 FileShare 模式去尝试打开——成功即未被占用，抛出 IOException（且 HResult == -2147024864 或消息含“正由另一进程使用”）即被独占。
注意：不能只捕获 UnauthorizedAccessException，因为权限不足和文件被占用都会触发它；必须检查异常的具体错误码或消息内容。
-
FileShare.Read模式下打开失败，说明有进程以FileShare.None或未包含Read的方式持有句柄 - 如果你后续要写入，必须用
FileShare.Read或更宽松的模式尝试，否则即使读取成功，写入时仍会失败 - 避免在 UI 线程频繁轮询检测，可能引发假死；建议配合
Task.Run或定时器做轻量探测
IOException 的 HResult 和消息需双重校验
.NET 中文件被占用抛出的 IOException 在不同系统版本、.NET 版本下表现不一致：HResult 可能是 -2147024864（即 0x80070020），也可能是 -2147024865（0x8007001F）；英文系统提示“The process cannot access the file...”，中文系统则为“另一个程序正在使用此文件，进程无法访问”。仅依赖其中一种判断容易漏判。
实操建议：
- 优先检查
ex.HResult == unchecked((int)0x80070020)（即-2147024864），这是最常见且稳定的标识 - 补充检查
ex.Message.Contains("used by another process") || ex.Message.Contains("正由另一进程使用") - 不要用
ex.InnerException判断——它常为 null，且无额外信息
为什么不用 File.Open 或 File.ReadAllText 做检测？
这些高层封装方法默认使用 FileShare.Read，且内部会自动处理部分共享冲突（比如某些日志文件被记事本打开时，File.ReadAllText 仍可能成功）。它们返回的是“能否读取内容”，而非“能否按你的意图打开”。一旦你后续要用 FileMode.Create + FileAccess.Write 覆盖写入，前面的“读取成功”毫无参考价值。
真正需要的不是“能不能读”，而是“我接下来要怎么开，现在能不能开”。所以必须显式构造 FileStream，传入和业务逻辑完全一致的 FileMode、FileAccess、FileShare 参数：
try {
using var _ = new FileStream(path, FileMode.Open, FileAccess.Read, FileShare.None); // 模拟独占读
return false; // 未被独占
}
catch (IOException ex) when (IsFileLocked(ex)) {
return true; // 被独占
}
检测后立刻操作仍可能失败？这是正常现象
文件锁是瞬态资源：A 进程检测时没锁，刚释放 FileStream，B 进程就打开了它——这是典型的竞态条件（race condition）。检测只能降低失败概率，不能消除。生产环境应把检测当作“快速预检”，而非“绝对保障”。
关键做法：
- 检测通过后，实际操作仍需包裹
try-catch，并重试逻辑（如延迟 100ms 后再试 2–3 次） - 对日志、临时文件等场景，可考虑用
Path.GetTempFileName()避开竞争，而非死磕原文件 - 若涉及跨进程协作，优先用命名互斥体（
Mutex）或文件锁约定，而不是反复试探
真正难的不是写检测代码，而是接受“锁不可靠”这个事实，并在架构层面对它做防御性设计。
