jsonconvert.deserializeobject报jsonserializationexception主因是类型定义不匹配，如字段名大小写不符、缺无参构造函数、readonly字段未配[jsonconstructor]或[jsonproperty]，而非json格式错误。
直接用 JsonConvert.DeserializeObject<t></t> 是最稳的起点，但前提是文件编码、结构、类型三者都对得上；否则不是报错就是静默丢数据。
为什么 JsonConvert.DeserializeObject 报 JsonSerializationException 却说不清哪错了
这个异常常被误认为是 JSON 格式错误，其实 80% 是 C# 类型和字段定义不匹配导致的。比如 JSON 里是 "user_name"，而类里写的是 public string UserName { get; set; }，默认大小写敏感，直接不认；又或者字段是 readonly 但没配 [JsonConstructor]，或缺少无参构造函数。
-
JsonConvert.DeserializeObject<myclass>(json)</myclass>要求目标类有 public 无参构造函数（除非用[JsonConstructor]指定） - private 或 readonly 字段必须加
[JsonProperty]才能参与序列化/反序列化 - JSON 中多出的字段默认被忽略——加
MissingMemberHandling = MissingMemberHandling.Error可提前暴露问题 - 日期字段若为 Unix 时间戳或自定义格式（如
"\/Date(1234567890000)\/"），需手动配DateTimeZoneHandling或自定义JsonConverter<datetime></datetime>
File.ReadAllText 不指定 Encoding.UTF8 就容易乱码或解析失败
Windows 记事本保存的 UTF-8 文件默认带 BOM，而 File.ReadAllText(path) 在未指定编码时会按系统默认编码（如 GBK）读取，结果中文变问号、JSON 结构被破坏，DeserializeObject 直接抛异常。
- 务必显式传
Encoding.UTF8：File.ReadAllText(path, Encoding.UTF8) - 读之前先检查文件是否存在且非空：
if (!File.Exists(path) || new FileInfo(path).Length == 0) - 用
try/catch包住反序列化逻辑，捕获JsonReaderException（含行号、列号）和JsonSerializationException，别让异常吞掉上下文
写入 JSON 文件时别拼字符串，也别漏掉转义
用 obj.ToString() 或字符串插值拼 JSON 再写入，会跳过 JsonConvert.SerializeObject 的转义逻辑，导致引号、反斜杠、控制字符全乱套，生成非法 JSON。
- 写入必须走
JsonConvert.SerializeObject，别绕开它 - 美化输出用
Formatting.Indented，但注意：它会让字符串体积增大，高频日志场景建议关闭 - 若要 HTML 安全（比如写入前端 JS 变量），加
StringEscapeHandling.EscapeHtml - 路径不存在？
File.WriteAllText不会自动建目录，得自己调Directory.CreateDirectory(Path.GetDirectoryName(path))
Newtonsoft.Json 还值得用吗？什么情况下必须换 System.Text.Json
Newtonsoft.Json 仍是 .NET Framework 和早期 .NET Core 项目的事实标准，尤其当你遇到 \/Date()\/ 这类非标时间格式、需要深度控制序列化行为、或已有大量 [JsonProperty] 注解时，它更灵活、报错更准。
但如果你在 .NET 6+ 新项目里，且没有特殊格式依赖，System.Text.Json 是更轻、更快、无额外包的选择。它的坑主要在大小写敏感、注释/尾逗号不支持、命名策略不内置 snake_case —— 这些都不是不能解，只是得主动配 PropertyNameCaseInsensitive = true 或 [JsonPropertyName("xxx")]。
真正容易被忽略的点是：Newtonsoft.Json 对 dynamic 和 JObject 的宽容度高，但这也意味着编译期检查失效，小问题拖到运行时才爆；而 System.Text.Json 强类型约束更硬，反而更容易在开发阶段发现问题。
