C# JSON反序列化中LitJson类型转换问题解决方案

1. 错误现象与背景解析

最近在调试一个C#项目时遇到了这个报错："JsonException: Can't assign value 'xxx'(type System.Double) to type System.Int64 at LitJson.JsonMapper"。这个错误发生在使用LitJson库进行JSON反序列化时，当JSON数据中包含浮点数但C#模型定义为long类型时就会触发。比如JSON中是{"price":19.99}但C#类里对应属性是public long price {get; set;}。

这种情况在实际开发中很常见，特别是在处理第三方API返回的数据时。很多API出于灵活性考虑会返回带小数点的数值，即使逻辑上这个字段应该是整数。比如电商系统中的价格字段，虽然显示时是两位小数，但存储时可能需要转换为以分为单位的整型。

2. LitJson的类型转换机制

2.1 LitJson的基本工作原理

LitJson是一个轻量级的C# JSON库，它的JsonMapper类负责在JSON字符串和C#对象之间进行转换。当遇到数值类型时，它会尝试以下转换规则：

1. 如果JSON中的数字没有小数点（如123），会优先尝试转换为int/long
2. 如果带有小数点（如123.45），则转换为double
3. 当目标属性类型与JSON值类型不匹配时，尝试隐式转换

问题就出在这个隐式转换上 - C#中double到long的转换不是隐式的，需要显式类型转换。

2.2 类型转换的边界情况

LitJson处理数值类型时有一些特殊行为需要注意：

• 对于整数范围的浮点数（如123.0），仍然保持double类型
• 超出long范围的整数（如1e20）会保持为double
• decimal类型有独立的处理逻辑

3. 解决方案与代码实现

3.1 方案一：修改模型定义

最直接的解决方案是调整C#模型定义，将属性类型改为double：

csharp复制public class Product {
    public double price {get; set;}  // 改为double类型
}

但这样会带来一些问题：

• 业务逻辑中可能需要大量类型转换
• 可能引入浮点数精度问题
• 不符合领域模型的语义（比如价格确实应该用decimal）

3.2 方案二：自定义JsonMapper设置

LitJson提供了自定义类型转换的扩展点。我们可以注册一个类型转换器：

csharp复制JsonMapper.RegisterExporter<double>((val, writer) => {
    writer.Write(Convert.ToInt64(val));
});

这样所有double值在序列化时都会转为long。但要注意：

• 会丢失小数部分
• 影响全局配置，可能产生副作用

3.3 方案三：使用中间DTO层

更健壮的做法是引入DTO层进行类型转换：

csharp复制public class ProductDto {
    public double price {get; set;}
}

public class Product {
    public long price {get; set;}
    
    public static Product FromDto(ProductDto dto) {
        return new Product {
            price = Convert.ToInt64(dto.price)
        };
    }
}

这样既保持了领域模型的纯洁性，又解决了反序列化问题。

4. 最佳实践与注意事项

4.1 数值类型的选择建议

根据业务场景选择合适的数据类型：

• 金额：优先使用decimal
• ID/计数：使用long
• 科学计算：使用double
• 小范围整数：使用int

4.2 处理第三方API的兼容性技巧

当处理不可控的API数据时：

1. 先用dynamic或Dictionary<string, object>接收
2. 进行类型检查和转换
3. 再映射到强类型模型

示例代码：

csharp复制var raw = JsonMapper.ToObject<Dictionary<string, object>>(json);
var product = new Product {
    price = raw.ContainsKey("price") ? Convert.ToInt64(raw["price"]) : 0
};

4.3 性能优化建议

大量数据处理时：

• 避免频繁的Convert操作
• 考虑使用System.Text.Json（.NET Core默认库）
• 对固定格式的API响应可以预编译反序列化逻辑

5. 扩展知识：其他JSON库的行为对比

5.1 Newtonsoft.Json的处理方式

Newtonsoft.Json在这方面更灵活：

• 提供FloatParseHandling设置
• 支持更丰富的类型转换配置
• 但体积和性能开销更大

5.2 System.Text.Json的特点

.NET Core默认库的行为：

• 默认不允许隐式类型转换
• 需要自定义JsonConverter
• 性能更好但灵活性稍差

6. 常见问题排查指南

6.1 错误场景重现表

(*取决于配置)

6.2 调试技巧

1. 使用JsonMapper.ToObject<Dictionary<string, object>>检查原始类型
2. 在Visual Studio调试器中查看JsonData的实际类型
3. 使用try-catch捕获JsonException并检查InnerException

6.3 典型错误案例

案例：从MongoDB读取的数据包含Double类型的ID

解决方案：

csharp复制public class Entity {
    [JsonIgnore]
    public double _id {get; set;}
    
    [JsonProperty("id")]
    public string Id => _id.ToString();
}

7. 替代方案与架构思考

对于长期项目，建议考虑：

1. 使用契约优先的API设计
2. 在API文档中明确数值类型规范
3. 在网关层统一处理类型转换
4. 建立团队内的JSON序列化规范

比如可以制定规则：

• 所有金额使用字符串类型避免精度问题
• ID字段禁止使用浮点数
• 枚举值使用整数而非字符串

8. 单元测试建议

为JSON反序列化编写专项测试：

csharp复制[Test]
public void Should_Convert_Double_To_Long() {
    var json = "{\"value\":123.0}";
    var obj = JsonMapper.ToObject<ModelWithLong>(json);
    Assert.AreEqual(123L, obj.value);
}

[Test]
public void Should_Fail_On_Real_Double() {
    var json = "{\"value\":123.45}";
    Assert.Throws<JsonException>(() => {
        JsonMapper.ToObject<ModelWithLong>(json);
    });
}

9. 版本兼容性说明

不同版本的LitJson行为可能有差异：

• 旧版本(<=1.0.0)对类型转换更宽松
• 新版本增加了更严格的类型检查
• 使用前应检查库版本和变更日志

10. 性能对比数据

测试环境：10000次反序列化操作

从数据可以看出，直接使用匹配的类型性能最好，但灵活性需要考虑业务需求。