nan 在 json 中被强制转为 null，因 json 规范仅允许有限数字，nan 属无效计算状态，非合法数值；序列化后不可逆，需用额外字段或约定标识其原始语义。

NaN 在 JSON 序列化中不会保留原值，而是被统一转为 null —— 这不是浏览器或引擎的“bug”，而是 JSON 规范（RFC 7159）的强制要求。

为什么 NaN 不能出现在 JSON 中

JSON 只定义了六种合法原始类型：字符串、数字、布尔值、null、数组、对象。其中“数字”必须是可解析的十进制有限值，而 NaN 是 IEEE 754 中的特殊状态，不属于“数”的语义范畴，它代表“计算结果无效”，不是某个具体数值。

• 规范原文明确禁止："Numeric values that cannot be represented in the grammar below (such as Infinity and NaN) are not permitted."
• 不同语言对 NaN 的内部表示和比较行为不一致（例如 NaN !== NaN），若允许序列化，接收方无法可靠还原或判断其原始意图
• JSON 的设计目标是跨语言互操作，不是完整映射 JS 运行时的所有特性

实际序列化行为：JavaScript 中的表现

调用 JSON.stringify({ x: NaN }) 得到的是 {"x":null}，而非报错。同理，Infinity 和 -Infinity 也转为 null。

Java Development Manual

Java开发手册规约集合，基于阿里巴巴Java开发手册（嵩山版）。 涵盖7大维度：编程规约、异常日志、单元测试、安全规约、MySQL数据库、工程结构、设计规约。 当用户需要：(1) 编写或审查Java代码 (2) 检查命名/代码规范 (3) 处理异常和日志 (4) 编写单元测试 (5) 安全编码 (6) 数据库设...

下载

• undefined、function、Symbol 等会被静默忽略（键值对消失）
• NaN 不会像 undefined 那样被跳过，而是显式替换为 null，但丢失了“这是 NaN”的元信息
• 反序列化后得到的是真正的 null，无法区分它原本是 null 还是 NaN

与 null 的关键区别

null 是 JSON 原生支持的合法值，语义清晰：表示“空值”或“缺失值”。而 NaN 是 JS 计算过程中的异常状态，二者在语义、规范地位和可恢复性上完全不同。

• null 序列化前后保持一致，且所有 JSON 解析器都按相同方式处理
• NaN → null 是单向映射，不可逆；没有标准机制能从 null 推断出原始是 NaN
• 若业务逻辑需区分“空”和“无效计算”，应改用字段标记（如 {"value": null, "status": "invalid"}）而非依赖 NaN

替代方案建议

若必须传递 NaN 含义，需主动设计语义层，而非依赖默认序列化：

• 提前将 NaN 显式转为 null，并在文档或 schema 中说明该字段为 null 时代表“无效数值”
• 使用额外字段标注状态，例如 { "score": null, "scoreStatus": "nan" }
• 在 replacer 函数中拦截 NaN，转为带标识的字符串（如 "__NaN__"），但需配套反序列化解析逻辑，且注意接收方是否支持
• 避免在需要精确数值语义的场景（如金融、科学计算）中混用 NaN 作为业务数据

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南