JSON 格式化后订单号变了：先检查大整数精度
轻工具编辑 · 配置与数据处理
通过 9007199254740993 的例子理解 JSON 数值精度问题，区分接口源数据、JavaScript 解析与显示格式化三个环节。
先确认编号是数字还是字符串
假设接口返回 {"orderId":9007199254740993}。这个数已经超过 JavaScript 安全整数范围，用普通数值类型解析后可能变成 9007199254740992。缩进本身没有算错，精度可能在解析步骤就丢失了。先在网络响应原文中核对，再与格式化结果比较，不要只看界面里排版后的文本。
最有效的处理通常在接口设计处
订单号、雪花 ID 和银行卡号通常不参与算术。接口若把这些标识符输出为字符串，例如 {"orderId":"9007199254740993"}，就可以保留每一位字符，也能保留前导零。不要把已被舍入的数字再转成字符串：丢失的位数无法靠加引号恢复。
需要保留数值类型时怎么办
如果字段确实用于精确计算，应使用支持大数或任意精度的解析、运算和序列化流程，并确认接收方也使用兼容类型。本站当前 JSON 格式化工具经过普通 JavaScript 数值解析，不适合承担这类无损转换。把业务标识符与数值量分开，是比增加缩进选项更重要的决定。
用最小样例复现，再检查整条链路
准备两条不含真实订单数据的样例：一条把长编号写成数字，另一条写成字符串。分别检查接口原文、前端解析、转换工具和保存后的文件。找到第一次发生变化的步骤，再修改该步骤的数据类型。格式化工具适合辅助阅读，不应该成为处理精度丢失的最后一道补救。
相关工具
内容如有错误，请通过联系页面提交脱敏样例和预期结果。