JSON序列化的本质
JSON（JavaScript Object Notation）是一种轻量级的数据交换格式，核心价值在于语言无关性和可互操作性。序列化（Serialization）是将内存中的数据结构转换为可传输/存储的字符串 表示的过程，反序列化则相反。
JSON规范支持的6种原始类型：
- 对象（object）
- 数组（array）
- 字符串（string）
- 数字（number）：只能是有限的十进制数
- 布尔值（true/false）
- null
NaN不能直接序列化的根本原因
核心原因：规范层面的硬性约束
RFC 7159（当前JSON标准）明确规定："Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted."
这里的设计哲学很清晰：JSON追求的是最大互操作性。NaN（Not a Number）是IEEE 754浮点标准中的特殊值，表示"非数字"概念，但这与JSON数字类型的语法定义直接冲突
- JSON数字必须是有限可解析的十进制形式
- NaN本身不是一个"数字"，而是"缺失数字状态"的元数据
- 如果允许NaN，不同语言/平台的解析器会产生巨大分歧（Java、C++、Python的NaN处理都有差异）
更深层的哲学：JSON要解决的是数据交换问题，而不是所有编程语言特性的完整映射。将NaN序列化为字符串"NaN"会导致语义模糊------接收方不知道这代表原始数据确实是NaN，还是用户输入了字符串"NaN"。
NaN vs None在JSON序列化中的差异
| 对比维度 | NaN（JavaScript/Python） | None（Python）/ null（JSON） |
|---|---|---|
| 语义本质 | 特殊浮点数值，表示"非数字" | 显式的空值/缺失值标记 |
| JSON规范支持 | 不支持 | 原生支持（null） |
| JavaScript序列化行为 | 转换为null（丢失类型信息） | 转换为null（保持语义） |
| Python序列化行为 | 输出"NaN"字符串（非标准，默认allow_nan=True） | 输出null（标准） |
| 反序列化后可区分性 | 无法与原始null区分 | 可区分 |
| 最佳实践 | 避免直接序列化 | 推荐使用 |
关键差异点：
- 规范合法性：null是JSON规范的一部分，而NaN不是
- 信息丢失：NaN序列化后（无论是转null还是字符串"NaN"），都无法恢复原始的"非数字"语义
- 互操作性：null在所有JSON解析器中行为一致，NaN处理则因实现而异
处理NaN值的实战解决方案
方案1：转换为null（推荐用于通用场景）
适用场景：数据丢失或无效时，用null表示"值不存在"
// JavaScript
const data = { value: NaN, count: 10 };
const cleanedData = {
...data,
value: Number.isNaN(data.value) ? null : data.value
};
JSON.stringify(cleanedData); // {"value":null,"count":10}
# Python
import math
import json
data = {"value": float('nan'), "count": 10}
cleaned_data = {
k: None if isinstance(v, float) and math.isnan(v) else v
for k, v in data.items()
}
json.dumps(cleaned_data) # {"value": null, "count": 10}方案2：使用字符串标记（需明确协议）
适用场景：必须区分"缺失"和"计算失败"时
data = {"result": float('nan'), "status": "ok"}
cleaned_data = {
k: "NaN" if isinstance(v, float) and math.isnan(v) else v
for k, v in data.items()
}
# {"result": "NaN", "status": "ok"}关键协议约定：双方必须明确约定字符串"NaN"代表数值计算失败，而非字面值。
方案3：自定义对象结构（最佳实践）
适用场景：复杂业务系统，需要保留完整上下文
# Python示例：使用对象包装
import json
from dataclasses import dataclass, asdict
@dataclass
class NumericResult:
value: float
valid: bool
error: str = None
def to_json_dict(self):
if not self.valid:
return {"value": None, "valid": False, "error": self.error}
return {"value": self.value, "valid": True, "error": None}
result = NumericResult(value=float('nan'), valid=False, error="Division by zero")
json.dumps(result.to_json_dict())
# {"value": null, "valid": false, "error": "Division by zero"}方案4：严格模式拒绝NaN（生产环境推荐）
Python严格模式：
# allow_nan=False时，遇到NaN会抛出ValueError
try:
json.dumps({"value": float('nan')}, allow_nan=False)
except ValueError as e:
print(f"Invalid data: {e}") # 显式失败，强制清洗数据JavaScript严格处理：
function safeStringify(obj) {
return JSON.stringify(obj, (key, value) => {
if (typeof value === 'number' && Number.isNaN(value)) {
throw new Error(`NaN found at ${key || 'root'}`);
}
return value;
});
}方案5：使用专业库（大规模系统）
# simplejson提供更细粒度控制
import simplejson
simplejson.dumps({"value": float('nan')}, ignore_nan=True)
# 自动转为null不同编程语言的NaN处理策略
| 语言/库 | 默认行为 | 严格模式 | 推荐方案 |
|---|---|---|---|
| JavaScript | NaN → null | replacer函数拦截 | 转null + 明确协议 |
| Python json | 输出"NaN"（非标准） | allow_nan=False → ValueError | allow_nan=False + 主动清洗 |
| .NET System.Text.Json | 报错 | JsonNumberHandling.AllowNamedFloatingPointLiterals | 转null |
| Java Jackson | 报错 | 配置WRITE_NULL_NUMBERS | 转null |
| Go encoding/json | 报错 | 无法配置 | 前置清洗 |
最佳实践建议
- 防御性编程：在序列化前主动清洗数据，而不是依赖序列化器的容错行为
- 明确协议：团队内部必须明确定义"数据缺失"、"无效数据"、"计算错误"的JSON表示
- 严格模式：生产环境使用allow_nan=False等严格配置，让问题尽早暴露
- 类型安全：考虑使用Typed JSON（如TypeScript接口、JSON Schema）在编译时/传输前验证
- 可追溯性：保留错误上下文，而不仅仅是转null
架构级思考
这个问题的本质暴露了JSON的设计哲学：简单性优先于完整性。如果你需要表示复杂数学状态、NaN、Infinity等IEEE 754特性，JSON不是最佳选择。可以考虑：
- MessagePack（支持NaN）
- Protocol Buffers（强类型）
- BSON（MongoDB扩展JSON）
但对99%的应用来说，前置清洗 + 转null 是最务实、最可维护的方案。