我不明白为什么当标准读取 json 配置文件时，配置参数以字符串形式出现，无论它们如何写入 json 文件。
让我解释一下。
在这里，我在 NET Core 8 上创建一个标准控制台项目，在那里添加依赖项Microsoft.Extensions.Configuration并Microsoft.Extensions.Configuration.Json
然后我直接写到Main
var builder = new ConfigurationBuilder().AddJsonFile("appSettings.json", false, false);
var configuration = builder.Build();
var rc = configuration["retryCounter"];
然后我添加 appSettings.json ，上面写着
{
"retryCounter": 42
}
...在代码中我得到一个值为“42”的字符串：
这是我不明白的地方：
我们的 json 已经输入了。是的，只有原始类型，但是数量
"retryCounter": 42
与字符串不同
"retryCounter": "42"
如果我使用我自己的类，某种
MySettings.cs带有其中描述的字段的类，并将其序列化 - 将其反序列化为 json - 那么我将进行到 json 的转换并返回，保留基本类型（int、string、float）同时，使用配置和ConfigurationBuilder是推荐的方式。也就是说，如果你做错了，那么在合适的地方他们会给你一个耳光。
那么为什么这个推荐路径如此有限并且与使用 ini 文件没有什么不同呢？这里有什么我不明白的意思吗，或者只是“世界上所有的数据都是字符串，我们不应该欺骗自己”？
简要地
使用这种配置方法的原因（在我看来）：
object，这将导致配置值的装箱/拆箱，要么您必须更改数据存储方式，这可能会“影响”多功能性。更多详情
在内部，.Build()
ConfigurationBuilder方法返回一个 ConfigurationRoot，后者又使用可用的ConfigurationProvider来获取配置值。ConfigurationProvider设计的方式是将配置数据存储为带有“键字符串”参数的字典，或者Dictionary<string, string?>由于 C# 是一种强类型语言，如果您想存储具有基本类型所需类型的数据，则必须使用Dictionary<string, object?>，并且在检索数据时，传递我们期望的输出类型（或使用dynamic）。事实证明不太实用，而且装箱/拆箱还有管理费用。毕竟，每个人都希望尽快收到配置并消耗更少的内存。此外，
ConfigurationProvider它是一个基本抽象类，可以在更具体的实现中重用。将所有值存储为键字符串对的想法在强类型编程语言中非常有意义。我们有一个严格的平面数据结构，其中可以通过组合键（这让人想起 Redis 缓存键）访问通用字符串值。结构很简单，我们得到了一个用于处理配置的通用接口，它可以通过任何其他方式来获取配置，而不仅仅是JSON（例如，从文本文件，从数据库等）。在某些类型是动态的 Javascript 中，使用原始类型存储值是合适的。