JSON 大整数与无损格式化指南

01 · JSON 数字与程序里的数字

JSON 中的数字最初是一段文本。工具如果先把它转成 JavaScript 的 Number，再重新序列化，就可能改变它。下面这个整数超过了 JavaScript 安全整数范围：

JSON.parse("9007199254740993")
// JavaScript Number 结果：9007199254740992

数字已经在解析时发生舍入，之后再增加缩进无法找回丢失的一位。因此，序匣使用保留源文本范围的解析方式，格式化时直接保留原始数字写法。

“语法合法”和“在某种程序数字类型中精确表示”是两件事。校验器中的精度警告用于提醒风险，不会擅自修改数据。

表格中的“普通解析后再序列化”指 JavaScript 的 JSON.parse 配合 JSON.stringify。本工具的美化和压缩还会保留键顺序、数组顺序与重复项，不清理字符串内部的空格。

例如 1e3 和 1000 表示相同的数值，写法却不同。排版格式化会尊重原始写法，避免顺便做一次没有被请求的数据规范化。

原始 JSON

{"orderId":9007199254740993,"ratio":1.00,"timeout":1e3,"offset":-0}

使用 2 空格的结果

{
  "orderId": 9007199254740993,
  "ratio": 1.00,
  "timeout": 1e3,
  "offset": -0
}

压缩会移除字符串之外不必要的排版空白，仍保留这些数字词法。再次用同样缩进格式化，结果应保持一致。

格式化不会改变你的接口约定，也不会让下游程序自动获得高精度数字能力。若长整数是标识符，可以与接口提供方约定用字符串传输；若需要精确计算，则应在使用它的程序中选择适当的数值类型。

遇到重复键时，同样不要把“看起来能解析”当作没有风险。例如 {"id":1,"id":2} 可能被其他工具折叠成一个字段。序匣会保留原始成员并给出警告，需要你确认哪一项才是业务上正确的内容。

保真格式化不会替你修改字段类型、删除重复键或修正业务值。修改这类内容前，先核对原始数据及接口约定。

看到数字精度警告，还能继续格式化吗？

可以。警告提醒你：其他使用普通 JavaScript Number 的工具可能丢精度。序匣的排版格式化保留原始数字 token，不会为了消除警告而把数字改成字符串。

只有一个数字或 null，为什么也能通过？

JSON 的顶层可以是对象、数组、字符串、数字、布尔值或 null。是否必须使用对象，是业务接口的约定，不是这里的通用语法限制。

键的顺序不一样，是否意味着 JSON 数据不同？

对象成员顺序不参与 JSON 的对象语义，但文本排列确实不同。文本比对会显示排版变化；JSON 结构比对按字段名匹配、忽略对象键顺序，并提供精确值与原始写法两种规则。数组按索引比较。Schema 校验尚未提供。