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拆开写。
