JSON格式化后长编号末位变了？先把标识符保留为字符串

原始文本里的编号是9007199254740993，格式化后却成了9007199254740992。JSON没有报错，末位仍然可能变化。排查这类问题时，先保存接口返回的原始文本，再检查编号有没有双引号；不要把格式化结果覆盖回原件。

ALIGG的JSON格式化工具在浏览器中先解析、再生成排版后的文本，使用的是JavaScript普通Number数值。它适合整理结构，但没有无损大整数解析模式。订单号、流水号等只用于识别记录的字段，最好由数据提供方在序列化时就按字符串输出。

用两个输入，看清变化发生在哪里

下面是专门构造的测试编号，不对应真实订单。在工具的“格式化”页，把第一段粘贴到“JSON 输入”，点击下方“格式化”按钮：

{"id":9007199254740993,"count":2}

当前工具输出为：

{
  "id": 9007199254740992,
  "count": 2
}

接着换成第二段，再点击“格式化”：

{"id":"9007199254740993","count":2}

这次id仍为"9007199254740993"，count仍为数值2。引号不是装饰：第一段请求解析器把id当数字，第二段让它保存一串字符。缩进选2个空格、4个空格或Tab，只影响排版，不能解决数值表示问题。

为什么不能简单记成“16位数字都不行”

JavaScript普通Number的最大安全整数是9007199254740991，也就是2的53次方减1。在安全范围内，每个整数都能准确区分；超出以后，某些整数仍能表示，某些相邻整数却会落到同一个值。例如9007199254740992本身可以表示，9007199254740993则不能按原值保存。这两个数都是16位，因此只按位数判断会出错。

JSON允许数字写法，并不等于每个接收程序都有任意精度能力。工具显示“JSON 有效”只表示语法解析成功，不代表业务编号、金额或每一位数字已通过无损校验。相同原因也影响本页的压缩和解析后转换；换一个按钮不能消除已经发生的舍入。

编号应该在哪里加引号

1. 回到可信的原始响应或原始导出文件，确认完整编号。若手里只剩舍入后的结果，先重新取原件。
2. 让提供数据的程序把标识符序列化成字符串，例如{"id":"9007199254740993"}，并与使用方约定字段类型。不要在解析完成后才把Number转字符串。
3. 把确认过的字符串版本放进工具，格式化后逐字比较id，并确认count等需要计算的字段仍是约定的数值类型。

已经变成9007199254740992的数，事后套上引号只能得到"9007199254740992"，不会找回原来的3。也不建议对整份JSON用正则把所有长数字一律加引号：字符串里的数字、指数写法和嵌套结构都可能被误伤。需要保持数字类型并做大整数运算时，应使用经过验证的任意精度方案；本站这个页面不提供该能力。

前导零是另一个信号。{"id":"00123"}能保留00123；{"id":00123}不是合法JSON数字，不能靠格式化补救。编号进入Excel后还会遇到单元格类型和显示格式问题，可接着看文本001与数值1的比对示例，不要把显示相同当成底层值相同。

几种容易混在一起的情况

只点“校验”，原输入没有变，是不是安全？校验不会把输出重新写回输入，但成功提示仍不能证明大整数无损。保留原文、检查类型和对照关键字段，才是这里需要的核查。

金额也全部改字符串吗？应先按接口契约决定类型和精度。标识符通常不参与算术，金额则涉及小数规则与计算方式，不能未经约定就批量改类型。

能用真实业务响应测试吗？先用文中合成数据复现即可。排查业务样本时应去掉令牌和个人资料。若还需要检查逗号、引号、括号等语法错误，可参考JSON格式化与校验入门；语法修正与精度核查是两项不同工作。