JSON 大整数精度丢失指南

这个页面解决什么问题

JSON 语法允许数字很长，但 JavaScript number 不能安全表示所有整数。订单号、雪花 ID、广告点击 ID、数据库主键、银行卡前缀、追踪编号等字段如果被当作数字进入浏览器或某些中间层，可能在展示前已经被舍入。格式化工具只能展示当前文本，无法恢复已经丢失的精度。

这类问题最危险的地方是“看起来差不多”。长 ID 的最后几位被改写后，接口仍可能返回 200，日志也可能显示一个合法数字，但业务对象已经变成另一个实体。

快速判断

• 字段名包含 id、order、trace、click、account、snowflake 时，优先判断是否应为字符串。
• 数字长度超过 15 到 16 位时，不要直接用 JavaScript number 做精确标识。
• 如果原始响应里 ID 没有引号，前端读取后可能已经发生舍入。
• 格式化后发现科学计数法或末尾多个 0，应回到源系统确认原文。

可复制示例：错误输入与修复后输入

坏样例把大 ID 写成数字；修复样例把它作为字符串保存，避免精度被 JavaScript number 改写。

{"orderId":9007199254740993123,"status":"paid"}

{"orderId":"9007199254740993123","status":"paid"}

在需要精确匹配的标识符场景，ID 是“符号”而不是可计算数值。只要不需要加减乘除，就更适合使用字符串。

诊断步骤

1. 确认字段业务含义：用于计算还是用于唯一标识。
2. 在原始响应、浏览器 Network、控制台对象和格式化文本之间逐一比较。
3. 如果控制台对象与 Network 原文不同，以原始响应体为准。
4. 将大整数 ID 在文档和 mock 中统一写成字符串。
5. 使用 文本对比工具 检查修复前后 ID 是否逐字符一致。

大整数问题不能只在格式化页面解决，必须回到 API 契约。提供方应把不可安全计算的标识符声明为字符串，消费方也不能强行转 number。

常见错误表

常见误判

• 把所有由数字组成的字段都当作 number。
• 在 mock 数据中随手写超长数字，导致测试环境已失真。
• 看到 JSON 格式化成功后忽视业务精度。
• 用 MD5 或 Base64 试图修复已被舍入的 ID。

一旦精度在上游丢失，下游工具无法恢复。正确修复点通常在接口定义、序列化层、数据库驱动或导出流程。

隐私、安全和适用边界

用于排查时请使用脱敏样本。不要粘贴访问令牌、Cookie、客户资料、内部域名、未公开商业规则、支付记录或完整生产日志。页面适合处理公开示例、教学片段、复现样本和已经替换真实值的配置。

本页不处理金额精度、税务计算和财务结算规则。涉及金额应使用项目指定的 decimal/字符串/分单位策略，并由财务或工程规范确认。

复制或发布前复核清单

1. ID 字段是否确实需要数学计算。
2. 超过安全整数范围的字段是否使用字符串。
3. 原始响应与格式化结果是否逐字符一致。
4. 文档、mock、测试和生产接口是否一致。
5. 导出到 CSV 或表格时是否保持文本格式。
6. 是否记录了修复点在服务端还是前端。

相关工具和延伸阅读

参考依据

• MDN Number.MAX_SAFE_INTEGER：JavaScript 安全整数边界。
• MDN JSON.parse()：JSON 数字进入 JavaScript 后的表示。
• Ymir Tool 文本对比工具：逐字符核对 ID 是否改变。

编辑记录：Ymir Tool editorial review，2026-06-01。本页作为 Sprint 3 新增案例/排错内容发布，目标是把单一工具入口扩展为可复核的任务说明、错误示例和操作边界。