ki-pi1. 问题现象与背景解析
最近在调试一个C#项目时，遇到了一个让人头疼的Json解析错误："JsonException: Can't assign value 'xxx' (type System.Double) to type System.Int64 at LitJson.JsonMapper"。这个错误发生在使用LitJson库进行JSON数据反序列化时，表面上看是类型不匹配的问题，但背后隐藏着一些值得深挖的细节。
LitJson是一个轻量级的JSON处理库，在Unity游戏开发和.NET应用中广泛使用。它通过JsonMapper类提供简单的序列化/反序列化功能。当JSON字符串中的数值类型与目标C#类的属性类型不一致时，就会抛出这类异常。具体到本例，错误信息明确告诉我们：JSON中包含了一个Double类型的数值（如3.14），但程序试图将其赋值给一个Int64（长整型）属性。
提示：这类类型转换问题在动态语言中可能不会报错，但在C#这种强类型语言中会严格检查，这也是保证代码健壮性的一种机制。
需要模型API调用？ 免费领10W Token，多模型网关一键接入 Claude、DeepSeek 等主流模型。
2. 错误根源深度剖析
2.1 LitJson的类型处理机制
LitJson在处理数值类型时有其特定的规则。当解析JSON中的数字时：
- 如果数字不带小数点（如42），LitJson会优先尝试解析为Int32、Int64等整数类型
- 如果数字带小数点（如42.0或3.14），则会被解析为Double类型
- 在反序列化到对象属性时，LitJson会尝试进行类型转换
问题的关键在于：LitJson默认不允许将浮点数(Double)直接赋值给整数类型(Int64)，即使这个浮点数实际上是一个整数值（如42.0）。
2.2 常见引发场景
这种错误通常出现在以下几种情况：
- 后端API返回的JSON中，某个字段有时返回整数有时返回浮点数
- 手动构造的JSON字符串中，无意中给某个字段添加了小数点
- 使用动态生成的JSON时，数值类型控制不严格
- 第三方API的响应数据格式发生变化，但客户端代码未同步更新
3. 解决方案与实战处理
3.1 快速修复方案
最直接的解决方案是统一数据类型。有两种方式：
- 修改C#类定义，将Int64改为Double：
csharp复制// 修改前
public long Quantity { get; set; }
// 修改后
public double Quantity { get; set; }
- 确保JSON数据中该字段始终以整数形式传递：
json复制// 修改前
{"quantity": 42.0}
// 修改后
{"quantity": 42}
3.2 高级处理方案
如果需要更灵活的类型处理，可以考虑以下方法：
- 自定义JsonMapper的类型转换逻辑：
csharp复制JsonMapper.RegisterImporter<double, long>((double value) => (long)value);
- 使用包装类处理特殊类型：
csharp复制public class LongWrapper {
[JsonIgnore]
public long Value { get; set; }
[JsonProperty]
private double TempValue {
set { Value = (long)value; }
}
}
- 实现自定义的JsonConverter：
csharp复制public class DoubleToLongConverter : JsonConverter
{
public override bool CanConvert(Type objectType)
{
return objectType == typeof(long);
}
public override object ReadJson(JsonReader reader, Type objectType, object existingValue, JsonSerializer serializer)
{
return (long)Convert.ToDouble(reader.Value);
}
// 其他必要方法...
}
4. 深入LitJson源码分析
要真正理解这个问题，我们需要看看LitJson的源码实现。在JsonMapper.cs文件中，有以下关键代码：
csharp复制private static void SetProperty(object obj, PropertyInfo prop, object value)
{
if (!prop.PropertyType.IsAssignableFrom(value.GetType())) {
// 类型不匹配时的处理逻辑
throw new JsonException($"Can't assign value '{value}' (type {value.GetType()}) to type {prop.PropertyType}");
}
prop.SetValue(obj, value, null);
}
这段代码清楚地展示了为什么会出现我们的错误：当属性类型(Int64)不能直接接受值类型(Double)时，就会抛出异常。
5. 最佳实践与预防措施
为了避免这类问题，建议采取以下开发实践：
- 前后端约定好数据格式规范，特别是数值类型的精度
- 在反序列化前添加类型检查：
csharp复制try {
var obj = JsonMapper.ToObject<MyClass>(jsonString);
} catch (JsonException ex) {
// 处理类型转换错误
Debug.LogError($"JSON解析错误: {ex.Message}");
}
- 使用单元测试验证边界情况：
csharp复制[Test]
public void TestDoubleToLongConversion()
{
var json = "{\"value\":42.0}";
var obj = JsonMapper.ToObject<MyClass>(json);
Assert.AreEqual(42L, obj.Value);
}
- 考虑使用更现代的JSON库（如Newtonsoft.Json或System.Text.Json），它们通常提供更灵活的类型转换选项
6. 类似问题扩展
这类类型转换问题不仅限于Double到Int64的转换，其他常见类似问题包括：
- JSON字符串数字与C#枚举类型的转换
- JSON中的"true"/"false"与C# bool类型的转换
- JSON中的null与C#值类型的处理
- 自定义日期时间格式的解析
每种情况都需要特别注意类型兼容性，可以通过类似的解决方案来处理。
7. 性能考量与优化
在处理大量JSON数据时，类型转换也会影响性能：
- 频繁的类型转换会增加CPU开销
- 异常处理机制在错误情况下会有性能损耗
- 使用泛型和缓存可以优化重复的类型转换
一个优化示例：
csharp复制private static readonly ConcurrentDictionary<Type, Func<object, object>> Converters =
new ConcurrentDictionary<Type, Func<object, object>>();
public static T ConvertValue<T>(object value)
{
var converter = Converters.GetOrAdd(typeof(T), t => {
// 创建并缓存类型转换器
return v => System.Convert.ChangeType(v, t);
});
return (T)converter(value);
}
8. 实际项目中的调试技巧
当遇到这类问题时，可以采用以下调试方法：
- 打印完整的JSON字符串，检查问题字段的值
- 使用在线JSON验证工具检查数据格式
- 在Visual Studio中使用"快速监视"查看反序列化过程中的类型信息
- 在LitJson源码关键位置添加调试输出
一个实用的调试代码片段：
csharp复制Debug.Log($"原始JSON: {jsonString}");
var wrapper = JsonMapper.ToObject<Dictionary<string, object>>(jsonString);
foreach (var kvp in wrapper) {
Debug.Log($"字段: {kvp.Key}, 类型: {kvp.Value.GetType()}, 值: {kvp.Value}");
}
9. 替代方案比较
如果LitJson的限制影响开发，可以考虑其他JSON库：
-
Newtonsoft.Json：
- 优点：功能全面，支持灵活的类型转换
- 缺点：体积较大，性能略低
-
System.Text.Json（.NET Core 3.0+）：
- 优点：官方库，性能优秀
- 缺点：功能相对较少，灵活性稍差
-
SimpleJSON（Unity常用）：
- 优点：轻量级，适合简单场景
- 缺点：功能有限，API不够友好
选择依据：
- Unity项目：根据项目大小选择LitJson或SimpleJSON
- .NET Core项目：优先使用System.Text.Json
- 需要复杂功能的项目：选择Newtonsoft.Json
10. 从设计角度预防类型问题
良好的程序设计可以避免大部分类型转换问题：
- 使用DTO（数据传输对象）明确接口契约
- 添加数据验证层，确保输入符合预期
- 采用防御性编程，处理边界情况
- 编写详细的API文档，明确每个字段的类型
例如，可以定义一个基类处理类型转换：
csharp复制public abstract class SafeJsonObject
{
protected static long SafeConvertToLong(object value)
{
if (value is long) return (long)value;
if (value is double) return (long)(double)value;
if (value is int) return (long)(int)value;
throw new ArgumentException($"无法将{value.GetType()}转换为long");
}
}
在实际项目中遇到这个错误后，我总结出一个经验：JSON反序列化时，类型一致性比我们想象的要重要得多。特别是在长期维护的项目中，随着需求变化和多人协作，数据类型很容易出现不一致。最好的做法是在项目初期就建立严格的数据类型规范，并在代码中添加足够的类型检查和转换逻辑，这样可以避免后期大量的调试时间。