c#中应优先通过异常的hresult属性提取win32错误码：对0x8007xxxx格式取低16位（hresult & 0xffff），如5对应error_access_denied；避免使用易被污染的marshal.getlastwin32error()。
Win32错误码怎么从C#异常里捞出来
绝大多数文件操作异常（比如 IOException、UnauthorizedAccessException）底层都封装了Win32错误码，但不直接暴露。关键是要用 Marshal.GetHRForException() 转成HRESULT，再用 Marshal.GetLastWin32Error() 或异常的 HResult 字段反推原始错误码。
常见错误现象：直接看异常消息“拒绝访问”或“找不到路径”，但没法区分是权限不足（ERROR_ACCESS_DENIED）、路径不存在（ERROR_PATH_NOT_FOUND），还是符号链接循环（ERROR_NOT_A_REPARSE_POINT）——这三者在业务逻辑里处理方式完全不同。
- 优先检查异常的
HResult属性：它通常已包含转换后的Win32错误码（高位清零后就是错误号） - 如果
HResult是 0x80070005 这类格式，取低16位：hresult & 0xFFFF就是标准Win32错误码（如5 =ERROR_ACCESS_DENIED） - 不要依赖
Marshal.GetLastWin32Error()—— 它容易被中间调用污染，除非你刚用DllImport调完原生API且没穿插其他P/Invoke
哪些Win32错误码在文件操作中最常出现
不是所有Win32错误都会在文件API里冒出来。真正高频的是那十几个，比如创建/删除/重命名/打开时反复撞上的几个：
-
ERROR_ACCESS_DENIED（5）：权限不够，或文件正被其他进程独占打开（注意：不是所有“拒绝访问”都是权限问题） -
ERROR_SHARING_VIOLATION（32）：另一进程以不兼容的共享模式打开了该文件（比如你试图写入，但它被只读打开） -
ERROR_FILE_EXISTS（80）和ERROR_ALREADY_EXISTS（183）：语义不同——前者用于要求“必须新建”的场景（如CreateFile带CREATE_NEW标志），后者多见于目录创建或注册表操作 -
ERROR_PRIVILEGE_NOT_HELD（1314）：尝试设置文件所有权或审计信息，但进程没开启相应特权（SeTakeOwnershipPrivilege等）
这些错误码定义在 winerror.h 里，.NET本身不提供枚举映射，建议自己建个静态字典或用 System.Runtime.InteropServices.Marshal 的辅助方法做转换。
File.Exists() 和 Directory.Exists() 为什么不能替代错误码判断
这两个方法返回 false 时，你根本不知道是路径不存在、没权限访问父目录，还是IO设备离线。它们内部其实也靠Win32 API（FindFirstFile）实现，但把所有失败都抹平成 false，丢掉了关键上下文。
- 例如：父目录存在但无读权限 →
Directory.Exists("D:\secret\sub")返回false，你以为子目录不存在，实际是权限拦住了 - 正确做法：直接调
File.Open()或Directory.GetDirectories()，捕获异常后解析HResult，按错误码分支处理 - 性能影响很小：一次系统调用 vs 两次（先Exists再Open），而且避免了竞态条件（Exists返回true，但Open时已被删）
跨平台代码里Win32错误码还能用吗
不能。.NET Core/.NET 5+ 在Linux/macOS上会把底层errno映射到相似的 HResult，但值完全不同（比如Linux的 EPERM 映射为 0x80070005，和Windows的 ERROR_ACCESS_DENIED 碰巧一致，但 ENOENT 是 0x80070002，对应Windows的 ERROR_FILE_NOT_FOUND）。硬写 if (errorCode == 5) 会导致Linux下逻辑错乱。
- 跨平台项目应优先用异常类型判断（
is FileNotFoundException、is UnauthorizedAccessException） - 如果必须依赖错误码（比如对接旧文档或调试需要），用
OperatingSystem.IsWindows()做平台分叉，再查对应码表 - 别信“Win32错误码在.NET里是跨平台兼容的”这种过时说法——那是.NET Framework时代在Windows上的幻觉
最麻烦的其实是符号链接和重解析点：Windows的 ERROR_NOT_A_REPARSE_POINT、ERROR_INVALID_REPARSE_DATA 在Linux上压根没有对应概念，这类路径操作的错误处理逻辑必须按OS拆开写。
