应使用 IntPtr.Size == 8 判断当前进程位数，最兼容所有 .NET 版本；Environment.Is64BitProcess 仅适用于 .NET Framework 4.0+ 和 .NET Core 2.0+；Environment.Is64BitOperatingSystem 仅反映系统位数，不反映进程位数。
Environment.Is64BitOperatingSystem 能直接用，但别只看它
这个属性返回 true 表示系统是 64 位操作系统，false 表示不是（即 32 位或 WOW64 下的 32 位进程）。但它只反映 OS 层面，不反映当前进程本身。
- 在 64 位 Windows 上以 x86 模式运行的 .NET 程序，
Environment.Is64BitOperatingSystem是true，但Environment.Is64BitProcess是false - .NET Framework 4.0+ 和 .NET Core 2.0+ 才支持
Environment.Is64BitProcess；旧版本需退回到IntPtr.Size == 8 - 不要用它判断“能否加载某 native DLL”，那得看进程位数是否匹配 DLL 位数
IntPtr.Size == 8 判断进程位数最兼容
这是最底层、最稳定的方式，适用于所有 .NET 版本（包括 .NET Framework 2.0+）。
-
IntPtr.Size == 8→ 当前进程是 64 位 -
IntPtr.Size == 4→ 当前进程是 32 位 - 注意：它和操作系统无关，只取决于编译目标（
AnyCPU+ “首选 32 位”勾选与否会影响实际运行时结果） - 常见误判场景：
AnyCPU程序在 64 位系统上默认跑成 64 位进程，但若勾选了“首选 32 位”，就会跑成 32 位进程 —— 此时IntPtr.Size仍是 4
Environment.GetEnvironmentVariable("PROCESSOR_ARCHITECTURE") 不可靠
这个环境变量常被拿来辅助判断，但容易被误导。
- 在 64 位 Windows 的 32 位进程中，它返回
x86（不是AMD64），因为 WoW64 会重写该变量 - 在 ARM64 设备上，它可能返回
ARM64，但 .NET 运行时未必支持该架构（如旧版 .NET Framework） - 它反映的是“Windows 告诉你什么”，不是“你实际跑在哪”，优先级低于
IntPtr.Size
需要区分 CPU 架构类型？用 RuntimeInformation.ProcessArchitecture
如果你真要区分 x64 / ARM64 / x86 / ARM，而不是只分 32/64，就得用 RuntimeInformation.ProcessArchitecture（.NET Core 2.0+ / .NET 5+）。
- 返回值是
Architecture枚举，比如Architecture.X64、Architecture.Arm64 - 在 .NET Framework 中不可用，必须迁移到 .NET Core 或更高版本
- 注意：它和
Environment.Is64BitProcess不等价 ——Arm64是 64 位，但Architecture.X86是 32 位，而Architecture.Arm（32 位 ARM）已基本淘汰
真正关键的不是“系统几比特”，而是“当前进程能加载什么 native 库”。IntPtr.Size 决定指针宽度，也决定了 P/Invoke 调用的 ABI 兼容性。很多人卡在 DLL 加载失败，其实只是没意识到自己编译成了 AnyCPU 却依赖了 x64-only 的 dll。
