Environment.GetEnvironmentVariable 返回 null 表示变量未定义而非为空；常见原因包括大小写不匹配（如用"path"而非"PATH"）、进程启动后修改未生效、调试时未配置项目环境变量，或跨平台大小写敏感问题。
Environment.GetEnvironmentVariable 用法与常见返回 null 场景
直接调用 Environment.GetEnvironmentVariable("PATH") 却返回 null？大概率不是代码写错，而是变量根本不存在于当前进程的环境上下文中。
- Windows 下区分大小写不敏感，但 .NET 运行时严格按字面匹配——
"path"（小写）在某些 PowerShell 启动场景下可能查不到，应统一用"PATH" - 环境变量只在进程启动时继承。若你在程序运行中用系统设置或命令行临时设了变量（如
setx FOO bar），新值不会自动注入已运行的 C# 进程，必须重启进程 - Visual Studio 调试时，环境变量来自“项目属性 → 调试 → 环境变量”配置，而非系统全局设置；未配置即为空
获取用户级 vs 系统级变量：Environment.GetEnvironmentVariables 的重载陷阱
Environment.GetEnvironmentVariables() 默认只返回当前进程环境块，不区分作用域；要读取注册表中保存的用户/系统级持久变量，必须显式指定目标：
- 读用户级（HKEY_CURRENT_USER\Environment）：
Environment.GetEnvironmentVariables(EnvironmentVariableTarget.User) - 读系统级（HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment）：
Environment.GetEnvironmentVariables(EnvironmentVariableTarget.Machine) - 注意：
User和Machine读取的是注册表快照，不是实时生效值；修改后需调用Environment.SetEnvironmentVariable(..., EnvironmentVariableTarget.User)并触发广播（如发送WM_SETTINGCHANGE）才能被其他进程感知
跨平台兼容性：Linux/macOS 下 PATH 分隔符与大小写敏感问题
在非 Windows 平台，Environment.GetEnvironmentVariable("PATH") 返回值用冒号 : 分隔路径，而非分号 ;；且变量名严格区分大小写。
- 硬编码
"Path"或"path"在 Linux 上必然失败，必须用"PATH" - 解析路径列表时别直接
.Split(';')，改用Path.PathSeparator（它在 Windows 是';'，Unix-like 是':'） - 某些 Linux 发行版（如 Ubuntu 桌面）默认不把
/usr/local/bin加入用户PATH，即使它存在于/etc/environment—— 因为 shell 登录脚本（如~/.profile）未显式导出，C# 进程也就继承不到
调试技巧：快速验证变量是否真存在且可读
别靠猜，用最简代码验证环境变量状态：
Console.WriteLine($"PATH = '{Environment.GetEnvironmentVariable("PATH")}'");
Console.WriteLine($"Is PATH null? {Environment.GetEnvironmentVariable("PATH") == null}");
Console.WriteLine($"User vars count: {Environment.GetEnvironmentVariables(EnvironmentVariableTarget.User).Count}");
如果输出 PATH = ''（空字符串）说明变量存在但值为空；如果是 null 才是未定义。另外，EnvironmentVariableTarget.Process 是默认目标，但显式写出更利于排查作用域混淆问题。
环境变量的“可见性”取决于进程创建时的上下文，而不是你期望它在哪出现；多数排错失败，是因为忘了环境变量不是全局广播信号，而是进程出生那一刻的快照。
