C#怎么读取配置文件_C# appsettings.json节点获取方法【基础】-C#.Net教程-PHP中文网

iconfiguration 是首选，因其默认注入且已自动加载多源配置、支持层级合并、类型转换与热更新；手动反序列化或 configurationbuilder 易绕过内置机制，导致环境配置失效或热重载失败。

c#怎么读取配置文件_c# appsettings.json节点获取方法【基础】

直接读取 appsettings.json 的节点，靠 IConfiguration 就够了，不需要手动反序列化或写 ConfigurationBuilder 链式调用——除非你有特殊加载路径或环境隔离需求。

为什么 `IConfiguration` 是首选？

ASP.NET Core 从 2.0 开始默认注入 IConfiguration 实例，它已自动加载 appsettings.json、appsettings.{Environment}.json 和环境变量等，层级合并、类型转换、重载监听都内置好了。手写 JsonSerializer.Deserialize 或 ConfigurationBuilder.AddJsonFile() 反而容易绕过这些机制，导致环境配置不生效、热重载失效、或类型转换失败。

常见错误现象：IConfiguration.GetSection("Logging").GetChildren() 返回空集合 → 实际是节点名大小写不匹配（JSON 键名区分大小写，但 C# 属性名常首字母大写）；或误用 GetValue<string>("Key")</string> 去读对象节点（该方法只适用于标量值）。

使用场景：Web API、Worker Service、甚至控制台项目（只要用了 Host.CreateDefaultBuilder）
参数差异：GetSection("ConnectionStrings") 返回 IConfigurationSection，而 GetValue<int>("Timeout")</int> 直接转基础类型
性能影响：无额外开销，IConfiguration 是只读快照，底层缓存键值对

`appsettings.json` 节点嵌套深时怎么安全取值？

深层嵌套（如 "Features:Auth:Enabled"）不能用点号拼字符串硬写，一来易错，二来无法静态检查。推荐用 GetSection 链式调用 + GetValue 或绑定到 POCO。

php版微信js-sdk支付接口类

下载

示例配置：

{
  "Features": {
    "Auth": {
      "Enabled": true,
      "MaxRetries": 3
    }
  }
}

正确做法：

config.GetSection("Features:Auth").GetValue<bool>("Enabled")</bool> → 返回 true
config.GetSection("Features:Auth").Get<authoptions>()</authoptions>，其中 AuthOptions 是含 public bool Enabled { get; set; } 的类
避免：config["Features:Auth:Enabled"] —— 返回 string，需手动 bool.Parse，且空值时抛异常

非 ASP.NET Core 项目（如传统 .NET Framework 控制台）怎么读？

没有 IConfiguration 注入时，必须手动构建 ConfigurationBuilder，但关键点是：路径要对、要调用 Build()、且 JSON 文件属性设为“复制到输出目录”。

确保 appsettings.json 的“复制到输出目录”设为“始终复制”或“如果较新则复制”
代码中写：var config = new ConfigurationBuilder().AddJsonFile("appsettings.json").Build();
错误现象：System.IO.FileNotFoundException → 路径不对，或文件没复制过去；GetValue<t>()</t> 返回默认值 → 节点名拼错，或 JSON 中该字段为 null 且未设默认值
兼容性注意：.NET Framework 需引用 Microsoft.Extensions.Configuration.Json NuGet 包（v3.1+ 支持 net461）

最易被忽略的是环境变量覆盖逻辑：即使 appsettings.json 里写了 "LogLevel": "Debug"，若系统环境变量设置了 LOGLEVEL=Warning，最终生效的是后者——这在 Docker 容器或 CI 环境中特别容易踩坑。