environment类可快速获取基础系统信息，轻量跨平台且无需管理员权限；但machinename仅返回netbios名，osversion为兼容性版本，processorcount为逻辑核心数，systemdirectory在非windows上未定义。
用 Environment 类快速读取基础系统信息
多数场景下，不需要引入额外组件或调用 Win32 API，Environment 类就能满足对运行环境的基本探查需求。它轻量、跨平台（.NET Core/.NET 5+），且不依赖管理员权限。
常见误用是试图用 Environment.MachineName 获取物理主机名以外的信息（比如 BIOS 版本或 CPU 型号），这会失败——它只返回 NetBIOS 名称，和 DNS 名称可能不一致；若需准确主机标识，应结合 Dns.GetHostEntry 或 NetworkInterface。
-
Environment.OSVersion返回的是兼容性版本（如 Windows 10 可能显示为 Windows 10.0.19045，但 .NET 运行时实际识别为 Windows 10），不能直接用于判断功能是否可用；推荐改用OperatingSystem.IsWindows()等运行时判断函数 -
Environment.ProcessorCount返回逻辑处理器数（含超线程），不是物理核心数；要区分物理/逻辑核心，需用ManagementObjectSearcher查询 WMI -
Environment.SystemDirectory是 Windows 系统目录路径（如C:\Windows\System32），在 Linux/macOS 上行为未定义，跨平台代码中应避免硬编码该值
用 ManagementObjectSearcher 查询硬件级系统信息
当需要获取 CPU 型号、内存容量、磁盘型号、BIOS 版本等底层信息时，WMI 是 Windows 平台最直接的途径。但要注意：它仅限 Windows，且默认需要 System.Management NuGet 包（.NET Core/.NET 5+ 必须显式安装）。
典型错误是未处理权限不足或 WMI 服务不可用的情况，导致抛出 UnauthorizedAccessException 或 ManagementException，程序直接崩溃。
- 查询前先检查
ManagementObjectSearcher是否可访问：用 try/catch 包裹初始化，并 fallback 到Environment提供的简化信息 - WQL 查询语句要精简，避免
SELECT *；例如查 CPU 型号用"SELECT Name FROM Win32_Processor"，比查全部字段快得多，也减少权限要求 - 在容器或受限环境（如 GitHub Actions Windows runner）中，WMI 可能被禁用；此时
ManagementObjectSearcher构造即失败，不能假设它总可用
RuntimeInformation 和 OperatingSystem 的跨平台适配要点
.NET 5+ 引入了 System.Runtime.InteropServices 下的 RuntimeInformation 和 OperatingSystem 类型，它们是真正跨平台、零依赖的替代方案，但容易被忽略其适用边界。
一个常见混淆是认为 RuntimeInformation.OSDescription 能返回详细系统版本（如 “Ubuntu 22.04.3 LTS”），实际上它只返回类似 “Linux 5.15.0-91-generic #101-Ubuntu SMP Tue Nov 14 13:30:08 UTC 2023” 的内核字符串，不含发行版名称；要获取发行版信息，仍需读取 /etc/os-release 文件。
-
OperatingSystem.IsAndroid()和OperatingSystem.IsIOS()在 .NET 6+ 才支持，旧版本调用会报编译错误 -
RuntimeInformation.FrameworkDescription返回的是运行时描述（如 “.NET 7.0.13”），不是 SDK 版本；想确认 SDK 版本需解析dotnet --version输出或检查global.json - 在 macOS 上，
RuntimeInformation.OSArchitecture可能返回Arm64或X64，但无法区分 Apple Silicon 的具体芯片代际（M1/M2/M3），这类细节需调用原生 sysctl
避免硬编码路径与注册表键导致部署失败
很多老代码习惯从 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion 读取 ProductName 或 BuildLabEx，或拼接 C:\Windows\Temp 作为临时目录。这些做法在非标准安装、容器、WSL 或非管理员账户下极易出错。
更隐蔽的问题是：某些注册表项在 64 位系统上对 32 位进程不可见（WoW64 重定向），导致读到空值或旧数据。
- 临时目录一律用
Path.GetTempPath()，它自动适配当前用户权限和环境变量 - 系统配置路径应优先走
Environment.GetFolderPath(Environment.SpecialFolder.System)，而非拼接字符串 - 读注册表前，明确指定
RegistryView.Registry64或RegistryView.Registry32，避免因进程位数与目标视图不匹配而读错键值 - 所有涉及路径或注册表的操作，必须加 null 检查和
IOException/UnauthorizedAccessException处理，不能假设路径一定存在或可读
系统信息看似简单，但真正稳定可靠的获取方式，取决于你到底要什么信息、跑在什么环境、以及能否接受 fallback。硬写死 WMI 或注册表路径，在开发机上跑得通，上线后就成定时炸弹。跨平台代码尤其要警惕那些“只在 Windows 上才有的属性”，它们不会报错，只会静默返回空或默认值。
