最常用方式是直接调用Environment.GetEnvironmentVariable读单个变量，它返回字符串或null，支持指定作用域但受平台和权限限制；批量读取用GetEnvironmentVariables；.NET 6+推荐通过IConfiguration统一管理以支持多源合并、热重载和测试。
直接用 Environment.GetEnvironmentVariable 读单个变量
这是最常用、最轻量的方式，适合明确知道变量名的场景。它默认只查当前进程的环境变量快照，不实时刷新系统级变更。
-
Environment.GetEnvironmentVariable("PATH")返回字符串，变量不存在时返回null - 第二个参数可指定作用域：
EnvironmentVariableTarget.Machine（读注册表 HKEY_LOCAL_MACHINE）或EnvironmentVariableTarget.User（HKEY_CURRENT_USER），但需注意：.NET Core / .NET 5+ 在非 Windows 平台不支持后两者，会抛PlatformNotSupportedException - Windows 上读取
Machine级变量需要管理员权限，否则静默返回null，不是权限错误提示
用 Environment.GetEnvironmentVariables 批量读取全部变量
返回 IDictionary，键为变量名（全大写，Windows 下不区分大小写但返回值统一为大写），值为字符串。适用于调试、配置探测等需要遍历的场景。
- 无参调用只返回当前进程环境块副本，不含新近由其他进程设置的全局变量
- 传入
EnvironmentVariableTarget.Process效果相同；传Machine或User同样受平台和权限限制 - 在容器（如 Linux Docker）中运行时，该方法仅反映容器启动时注入的环境，不包含运行时
export的新变量
读不到刚设置的系统变量？注意进程继承机制
Windows 和 Linux 都不会自动将新设的系统级环境变量“推”给已运行的进程。C# 程序启动时从父进程（如终端、IDE、服务管理器）继承环境快照，之后独立存在。
- 修改注册表或
/etc/environment后，必须重启你的 C# 进程（不是重新编译，是彻底关闭再启动） - 在 PowerShell 中执行
$env:FOO="bar"只影响该 Shell 及其子进程，不影响已运行的 dotnet 进程 - 验证是否生效：用
Process.Start("cmd", "/c set")启动新 cmd 查看实际环境，比依赖 IDE 的调试环境更可靠
.NET 6+ 推荐用 IConfiguration 统一管理，而非硬编码读取
如果变量用于配置（如数据库连接串、API 密钥），直接调 GetEnvironmentVariable 容易散落各处、难测试、无法 fallback。应交由配置系统接管。
var builder = new ConfigurationBuilder()
.AddEnvironmentVariables(); // 自动加载所有环境变量
var config = builder.Build();
<p>string dbConn = config["ConnectionStrings:Default"]; // 按前缀映射
string logLevel = config["Logging:LogLevel:Default"] ?? "Information";</p>-
AddEnvironmentVariables()默认只加载以DOTNET_、ASPNETCORE_开头的变量（.NET 6+ 行为），如需加载全部，传入空字符串：AddEnvironmentVariables("") - 变量名中的双下划线
__会被转为配置层级分隔符，例如LOGGING__LOGLEVEL__DEFAULT→Logging:LogLevel:Default - 这样写的好处：可与 JSON、命令行参数等其他源合并，支持热重载（
reloadOnChange: true），单元测试时容易 Mock
环境变量不是实时广播信道，而是进程启动时的一次性快照。真正要动态响应变化，得自己监听文件、注册表或信号，而不是指望 GetEnvironmentVariable 突然变出新值。
