environment.getenvironmentvariable读不到自定义变量主因是变量未生效或作用域不匹配：windows系统变量需重启终端，用户变量可能未被继承；默认读取进程启动时快照，须用environmentvariabletarget指定machine/user才查注册表；跨平台时machine/user退化为process。
Environment.GetEnvironmentVariable 读不到自定义变量？
多数情况不是代码写错了，而是变量没生效或作用域不对。Windows 下新建的系统环境变量要重启终端才生效，而用户级变量在当前会话里可能压根没被子进程继承。
- 检查变量是否真的存在：
echo %YOUR_VAR%（CMD）或echo $env:YOUR_VAR（PowerShell） - 确认是“系统变量”还是“用户变量”——C# 默认读取的是当前进程启动时继承的那一份，不会动态刷新
- 如果用 Visual Studio 调试，改完变量后必须**完全关闭 VS 再重开**，仅重启调试器不够
- 避免拼写大小写错误：
Environment.GetEnvironmentVariable("Path")可以，但"path"在 Windows 上通常返回null
GetEnvironmentVariable 第二个参数 EnvironmentVariableTarget 怎么选？
这个枚举控制读取范围，不传默认是 EnvironmentVariableTarget.Process，也就是只查当前进程已加载的副本；真正想查注册表里的原始定义，得显式指定目标。
-
EnvironmentVariableTarget.Machine：读 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Session Manager\Environment，需要管理员权限才能写，读一般没问题 -
EnvironmentVariableTarget.User：读 HKEY_CURRENT_USER\Environment，普通用户可读可写 -
EnvironmentVariableTarget.Process：最常用，但注意它只是快照——进程启动后，外部改系统变量对它无效 - 跨平台注意：Linux/macOS 不支持
Machine和User，传了也退化为Process
为什么有时候返回 null，但 cmd 里能 echo 出来？
根本原因是进程继承链断了。比如你从桌面快捷方式启动程序，它继承的是登录会话的环境，而你在终端里 set 的变量只存在于那个终端进程及其子进程里。
- 在 CMD 中用
set VAR=xxx设置的是临时变量，只对该 CMD 窗口有效 - 用
setx VAR xxx才写入注册表，但新值要下一次启动的进程才可见 - VS Code 终端、PowerShell ISE、.NET CLI 工具链各自维护一份环境缓存，改完记得关掉再开
- 容器或服务场景下，环境变量由宿主注入，
GetEnvironmentVariable读到的就是容器启动时传入的那批
读取 PATH 这类复合变量要注意什么？
PATH 是典型用分号（Windows）或冒号（Unix）拼接的字符串，直接当完整字符串处理容易出错，尤其涉及路径转义、空格、重复项时。
- 别用
.Split(';')粗暴分割——某些路径含空格甚至分号（虽然罕见），应优先用Environment.GetEnvironmentVariable("PATH")?.Split(Path.PathSeparator) -
Path.PathSeparator自动适配平台，比硬写';'或':'更可靠 - 如果要做路径存在性判断，记得用
Path.IsPathRooted()或File.Exists()验证，别只靠字符串匹配 - 修改
PATH后立即调用GetEnvironmentVariable仍返回旧值——因为Process级变量不可写，只能通过SetEnvironmentVariable影响后续子进程
环境变量不是全局实时数据库，它是一次性快照 + 注册表备份的混合体。最常被忽略的是“谁启动了你的程序”——IDE、终端、服务管理器、CI runner，它们各自加载环境的方式决定了你能读到什么。
