c#如何读取JSON文件_c#读取JSON文件深入理解与底层原理

.NET 6+ 推荐用 System.Text.Json.Deserialize 读取 JSON，需确保类型匹配、启用宽松解析处理注释和尾逗号，动态场景用 JsonDocument，大文件用流式解析避免 OOM

用 JsonSerializer.Deserialize 读取 JSON 文件最直接，但必须匹配类型定义

当JSON结构固定、字段明确时，.NET 6+内置的System.Text.Json无疑是首选。它不依赖任何第三方包，序列化与反序列化的路径短，内存占用也低。不过，这里的关键从来不是“能不能读”，而是“类型对不对”——Deserialize方法可不会自动忽略多余的字段，也不会自作主张地把null字符串转换成0或者false。

一个常见的报错现象是：JsonSerializer.Deserialize抛出一个JsonException: The JSON value could not be converted to xxx。这往往意味着，你定义的类中某个属性的类型，和JSON里的实际值“对不上号”。比如，JSON里明明是个带引号的"123"字符串，C#属性却定义成了int类型。

• 务必确保目标类中所有非可空的引用类型字段，在JSON里都有对应的值。如果字段可能缺失，那就把它声明为string?、int?这类可空类型。
• 利用JsonSerializerOptions.PropertyNameCaseInsensitive = true这个配置，可以有效避免因大小写不一致导致的匹配失败。
• 如果JSON里包含日期字符串（比如"2024-05-20T14:30:00"），C#这边直接用DateTime属性接收就行，无需手动解析——前提是格式符合ISO 8601标准，这是默认支持的。
• 切忌使用object或dynamic来接收数据然后再强制转换。这种做法绕过了编译期的类型检查，只会把问题隐藏起来，拖到运行时再爆发。

JSON 文件含注释或尾部逗号？JsonSerializer 默认不认，得开配置

.NET原生的JsonSerializer默认只认“标准”的JSON（遵循RFC 8259规范）。这意味着，行内注释（//）、块注释（/* */），甚至是对象末尾多出来的那个逗号（{"a":1,}），它一概不接受。直接用默认设置去读取这类“非标”文件，会直接抛出一个JsonException。

解决办法其实很简单：启用宽松解析模式。具体来说，就是设置JsonSerializerOptions.ReadCommentHandling = JsonCommentHandling.Skip来跳过注释，同时设置JsonSerializerOptions.AllowTrailingCommas = true来允许尾部逗号。

来看个示例：

var options = new JsonSerializerOptions
{
    PropertyNameCaseInsensitive = true,
    ReadCommentHandling = JsonCommentHandling.Skip,
    AllowTrailingCommas = true
};
var data = JsonSerializer.Deserialize(File.ReadAllText("config.json"), options);

有两点需要特别注意：第一，这两个选项只影响反序列化（读取）过程，对序列化（写入）无效；第二，即便开启了宽松模式，它依然不支持单引号字符串或者属性名不加引号这类写法——这些已经超出了JSON标准的范畴，真遇到的话，恐怕就得考虑换解析器了。

不知道结构、要查字段名或动态改值？用 JsonDocument 更轻量安全

当JSON的来源不可控时——比如只是一段配置片段、API返回的部分数据，或者是用户上传的文件——我们可能并不想（或无法）定义一个完整的类来映射。这时候，JsonDocument就是一个比Newtonsoft的JObject更轻量、更节省内存的选择。它只做只读解析，不会构建完整的对象图，非常适合那种“查一下就用完”的场景。

不过，这里有个常见的误用点：有人会使用JsonElement.Clone()来多次访问同一个节点。其实JsonElement是结构体（struct），复制成本很低。真正容易出问题的是，在频繁调用GetProperty查询嵌套字段时，忽略了TryGetProperty的返回值判断，从而导致InvalidOperationException: Cannot access child value on a value of type Undefined这样的异常。

• 最稳妥的做法是，永远先用TryGetProperty("xxx", out var element)来判断字段是否存在，而不是直接调用root.GetProperty("xxx")。
• 读取数值时，应该使用element.GetInt32()、element.GetDouble()这类专门的方法，而不是用element.ToString()拿到字符串再转换——后者拿到的是原始的JSON文本片段，可能还带着引号或空格。
• 使用JsonDocument.Parse解析后，一定要记得调用Dispose()，或者直接用using语句包裹。否则，底层的缓冲区将不会被释放。

读大文件时卡死或 OOM？别一次性 File.ReadAllText

如果你用File.ReadAllText("huge.json")去加载一个几百MB的JSON文件，程序会在瞬间分配一个同等大小的字符串内存，这极易触发垃圾回收（GC）压力，甚至直接抛出OutOfMemoryException。问题往往不是出在JSON解析慢，而是在字符串加载阶段，内存就已经撑不住了。

正确的做法是采用流式处理：结合FileStream和Utf8JsonReader，边读取边解析，这样内存占用可以恒定在几KB的级别。

这种方案特别适用于处理JSON Lines格式的日志、传感器批量上报的数据，或者导出的数据库快照（每行一个独立的JSON对象）。

• 对于逐行读取的场景，使用File.ReadLines("data.jsonl").Select(line => JsonDocument.Parse(line))，远比把整个文件读入内存再分割要安全得多。
• 如果遇到真正庞大的单体JSON文件（比如某些GeoJSON数据），则需要手动使用Utf8JsonReader来推进读取，跳过那些不需要的数组或对象层级，只提取关键字段。
• 另外，尽量避免在循环里反复创建新的JsonSerializerOptions实例。这个对象是可以复用的，并且是线程安全的。

从底层原理来看，Utf8JsonReader直接操作字节流，不生成中间的字符串；而JsonSerializer.Deserialize底层也是基于它构建的，只是额外封装了类型映射的逻辑。所以，当有人问“为什么不用Newtonsoft.Json”时，本质上是在做一个权衡：你的项目是否需要支持注释、宽松语法或者复杂的自定义转换器？如果需要，那就引入第三方包；如果不需要，那么原生的System.Text.Json在性能和资源开销上，通常是更优的选择。