最稳方案是调用 sysinternals 的 handle.exe 工具，如 handle.exe -a "c:\temp\log.txt"，解析输出获取占用文件的 pid 和进程名；不推荐 p/invoke 枚举句柄因兼容性差、权限高、易蓝屏。
如何用 GetProcesses() 和 HandleScanner 定位占用某文件的进程
Windows 下没法直接删文件，十有八九是别的进程正拿着句柄——但 Process 类本身不暴露句柄映射关系，得靠外部工具或底层 API 补足。C# 标准库没提供“查谁在读这个路径”的函数，必须组合使用。
实操上最稳的路是调用 handle.exe（Sysinternals 工具），配合解析输出；或者用 P/Invoke 调 NtQuerySystemInformation + DuplicateHandle 自行枚举，但后者兼容性差、权限要求高、容易蓝屏，不推荐日常用。
-
handle.exe -a "C:\temp\log.txt"是最快验证方式，输出里带 PID 和进程名 - 把
handle.exe嵌入 C# 用Process.Start()调起，再读StandardOutput，注意加-accepteula避免弹窗阻塞 - 别信
File.Open(..., FileMode.Open, FileAccess.Read, FileShare.None)能“探测占用”——它自己就会抛IOException，但错误信息里没有肇事进程名
为什么 FileStream 的 SafeFileHandle 不能反查进程归属
因为 SafeFileHandle 只是当前进程内一个内核对象引用，类似指针，不携带创建它的上下文。Windows 内核里句柄表是按进程隔离的，跨进程查归属必须走系统级句柄枚举，不是 .NET 运行时能解决的事。
常见误解是以为调 fileStream.SafeFileHandle.DangerousGetHandle() 拿到那个 IntPtr，就能喂给某个 API 反查——实际上没有任何公开 Win32 API 接收裸句柄值来返回 PID。
- 所有“通过句柄找进程”的方案，本质都是：先遍历所有进程 → 对每个进程再遍历它的句柄表 → 比对句柄指向的对象名（如文件路径）
-
SafeFileHandle在 .NET 6+ 后默认启用IsInvalid检查，如果底层句柄已被关闭，再访问会抛ObjectDisposedException，不是IOException - 别在
finally里手动CloseHandle——SafeFileHandle的Dispose已经做了，重复调用可能触发 AV
用 ETW 或 FileSystemWatcher 捕获文件操作事件的局限性
FileSystemWatcher 只能告诉你“哪个路径被改了”，不告诉你“谁改的”。它基于 ReadDirectoryChangesW，本质是目录通知，连操作类型（Create/Delete/Write）都常不准，更别说进程上下文。
真要关联进程和操作，得上 ETW（Event Tracing for Windows），监听 Microsoft-Windows-Kernel-File 提供器，里面带 ProcessId 字段。但代价高：需要管理员权限、ETW session 管理复杂、事件过滤难写、.NET 中没原生封装，得靠 Microsoft.Diagnostics.Tracing.TraceEvent 库。
-
FileSystemWatcher的EnableRaisingEvents = true之后，首次Created事件可能漏掉——因为底层缓冲区溢出，建议启动后先 sleep 100ms 再操作 - ETW 采集到的
FileIoWrite事件里，ProcessId是可靠的，但ImageFileName（进程路径）字段在 Win10 1809+ 才稳定填充，旧系统常为空 - 别用 ETW 监控整个 C: 盘——每秒几万事件，.NET 处理不过来，
TraceEventSource会丢事件，优先过滤路径前缀
C# 中模拟“文件操作链路追踪”的可行折中方案
纯托管代码做不到完整跨进程追踪，但可以在自己可控的范围内埋点：统一用封装过的 FileOperationService 替代裸 File 静态方法，并在每次操作时记录 Process.GetCurrentProcess().Id、线程 ID、调用栈（Environment.StackTrace 截取前几帧）、时间戳、参数路径。日志写进本地 SQLite 或内存队列，出问题时查表比对。
这法子不解决“别人进程占着我文件”的问题，但能快速定位“是不是我自己的某段代码反复打开没关”，排查效率提升明显。
- 关键不是记全量，而是记
File.OpenRead/File.Create/new FileStream这三类易泄漏的操作入口 - 用
ConcurrentDictionary<string list>></string>按路径聚合日志，查冲突时直接dict[path]就能看到所有操作记录 - 别依赖
GC.Collect()强制回收FileStream——析构函数调用时机不确定，且 .NET 6+ 默认禁用终结器，Dispose必须显式调
跨进程文件操作关联这件事，本质上是个操作系统权限与抽象层级的问题。越想在用户态“无侵入”地看清全局，越要接受性能损耗、权限提升、兼容性妥协这三样东西——没有银弹，只有权衡点在哪。
