Blazor 应用（尤其是 Blazor Server 和 Blazor WebAssembly 从 .NET 6+ 开始）支持通过
appsettings.json实现环境感知的配置，但具体机制因托管模型不同而有差异。核心原则是：**环境变量决定加载哪个配置文件，而非手动切换文件名**。
Blazor Server：完全兼容 ASP.NET Core 配置体系
Blazor Server 本质是服务端渲染，直接复用 ASP.NET Core 的配置系统，支持多环境配置文件自动合并：
基础文件：appsettings.json（所有环境共享） 环境专属文件：
appsettings.Development.json、
appsettings.Production.json等 生效逻辑：运行时根据
ASPNETCORE_ENVIRONMENT环境变量值（如
Development）自动加载对应文件，且环境文件会覆盖基础文件中同名配置项 使用方式：在
Program.cs中通过
builder.Configuration注入，例如
builder.Services.Configure<myoptions>(builder.Configuration.GetSection("MySettings"))</myoptions>
Blazor WebAssembly：客户端配置需主动加载，不依赖环境变量
WebAssembly 运行在浏览器中，无法读取服务器环境变量，因此配置加载是显式、静态的：
默认行为：只加载根目录下的appsettings.json（开发时）和
appsettings.{Environment}.json（发布后）
环境匹配逻辑：构建/发布时，SDK 根据 <environmentname></environmentname>MSBuild 属性（如
Production）自动复制对应文件（如
appsettings.Production.json）并重命名为
appsettings.json，覆盖默认文件 手动指定环境：可在
index.html的
<script></script>标签中添加
autostart="false"，然后调用
Blazor.start()并传入
{ environment: 'Staging' } —— 但这仅影响 Blazor 自身日志级别等内部行为，不触发配置文件切换
真正生效的配置方式：发布前设置项目文件中的 <environmentname>Staging</environmentname>，或使用
dotnet publish -c Release -p:EnvironmentName=Staging
通用建议：避免硬编码，优先用强类型配置
无论哪种 Blazor 模型，都推荐将配置抽象为 C# 类，提高可维护性与类型安全：
定义配置类，如public class ApiSettings { public string BaseUrl { get; set; } }
在 appsettings.json中写入对应结构：
"ApiSettings": { "BaseUrl": "https://api.example.com" }
注册强类型绑定：builder.Services.Configure<apisettings>(builder.Configuration.GetSection("ApiSettings"))</apisettings>
在组件中注入 IOptions<apisettings></apisettings>或
IOptionsSnapshot<apisettings></apisettings>使用
调试技巧：确认当前加载的配置内容
快速验证配置是否按预期加载：
Blazor Server：在Program.cs中临时加
Console.WriteLine(builder.Configuration["MyKey"]);Blazor WebAssembly：在
Program.cs的
builder.Services.Add...()前，用
await builder.Configuration.ReloadAsync();确保已加载完成，再打印
builder.Configuration.AsEnumerable()查看全部键值对 浏览器开发者工具中检查网络请求，确认加载的是
appsettings.json还是
appsettings.Production.json
基本上就这些。关键区别在于：Server 看环境变量自动选，WASM 看构建时指定的
EnvironmentName静态打包。不复杂但容易忽略细节。
