Environment.SetEnvironmentVariable仅影响当前进程，子进程可继承但父进程及其他进程不可见，不修改系统/用户级变量，仅支持Process目标，线程安全但需注意并发读写同步。
Environment.SetEnvironmentVariable 只影响当前进程
调用 Environment.SetEnvironmentVariable 后，环境变量只在当前 .NET 进程内生效，子进程（比如通过 Process.Start 启动的程序）默认会继承这个新值，但父进程或其他已运行进程完全看不到变化。
常见错误现象：
– 在代码里设了 MY_CONFIG_PATH，然后立刻用命令行工具（如 cmd.exe 或 dotnet run 重启）验证，发现没生效
– 误以为改了系统级环境变量，结果部署到服务器后配置读不到
- 只对当前
AppDomain（.NET Framework）或当前进程（.NET Core/.NET 5+）有效 - 若需影响子进程，必须在启动前设置，例如：
Environment.SetEnvironmentVariable("API_TIMEOUT", "30000");<br>var proc = Process.Start("curl.exe", "-s https://api.example.com"); - 多线程安全：该方法是线程安全的，但并发读写同一变量时，仍需自行同步逻辑
不能通过 Environment.SetEnvironmentVariable 修改系统/用户级变量
Windows 的“系统属性 → 高级 → 环境变量”或 Linux 的 /etc/environment、~/.bashrc 中的变量，C# 运行时无权直接写入——这需要管理员权限 + 调用 Win32 API（Windows）或 shell 配置文件操作（Linux/macOS），且不推荐在业务代码中做。
使用场景：
– 临时覆盖测试配置（如 CI 中注入密钥）
– 避免硬编码路径，让本地调试更灵活
– 不适用于“安装程序设置全局 PATH”这类运维需求
- 试图用
Environment.SetEnvironmentVariable("PATH", "C:\mytools;" + Environment.GetEnvironmentVariable("PATH"), EnvironmentVariableTarget.Machine)会静默失败（.NET 不支持Machine/User目标写入） -
EnvironmentVariableTarget.Process是唯一可写的枚举值，传其他值会被忽略 - Windows 上若真要改注册表级变量，得用
Microsoft.Win32.Registry+ 管理员权限，但修改后需广播WM_SETTINGCHANGE，普通应用不该碰
跨平台行为差异：Linux/macOS 下大小写敏感，Windows 不敏感
Environment.SetEnvironmentVariable("HOME", "/tmp/test") 在 Linux 上会新建一个 HOME，但不会覆盖原有 home（如果存在）；Windows 则统一按不区分大小写处理，同名变量会被替换。
性能 / 兼容性影响：
– 每次调用都是托管层到 OS 的一次小开销，高频设置（如循环内）会影响性能
– .NET 6+ 对重复设置相同值做了轻量缓存，但不要依赖
- 避免在 hot path（如 HTTP 请求中间件每请求都设）中调用
- 若需大量变量注入，建议一次性构造
ProcessStartInfo.EnvironmentVariables字典传给子进程，而不是逐个SetEnvironmentVariable - Linux 容器中，环境变量通常由
docker run -e或ENV指令注入，运行时修改仅限容器内进程可见
读取时要注意 Environment.GetEnvironmentVariable 的返回值
Environment.GetEnvironmentVariable 返回 null 表示变量不存在，不是空字符串。很多代码直接 .ToString() 或拼接，结果抛出 NullReferenceException。
容易踩的坑：
– 把 Environment.GetEnvironmentVariable("DEBUG") == "1" 当作布尔判断，但变量未设置时会判 false，掩盖缺失配置问题
– 使用 ?? "" 后再解析数字，导致 int.Parse(null ?? "") 崩溃
- 安全读取整数建议：
if (int.TryParse(Environment.GetEnvironmentVariable("RETRY_COUNT") ?? "3", out int retry))<br>{ /* use retry */ } - 检查是否存在用
Environment.GetEnvironmentVariable("X") is not null，别用!= null（语义等价但可读性差） - 若变量应始终存在，建议在应用启动早期校验并报错，而不是等到首次使用才崩
环境变量不是配置中心，它适合传简单、不可变、进程粒度的开关和路径；真正复杂的配置应该走 JSON 文件、Consul 或 Azure App Configuration。别指望靠反复 SetEnvironmentVariable 实现运行时热更新——那不是它的设计用途。
