数据格式与结构化数据

大 ID 的末位变了，如何检查 JSON 精度？

使用工具

订单号没有计算，只复制后末位就变了。解析成数字本身就可能丢精度。应区分原 JSON 的数字字符与解析后数值，先用两个相邻虚构 ID 检查能否区分。

必须区分的两个数字

{"first":9007199254740992,"second":9007199254740993}

直接贴入 JSON 整形工具，保精度解析器会保留末位 2 与 3。不是只检查无报错，还要检查输出完整值不同，不要只看缩略标签或分组显示。

其他程序返回的 second 也变成末位 2 时，链路某处已丢信息。本工具正确不保证前后应用也正确。分别比较原始响应、解析后、显示值与保存重读值，定位首次变化。

以字符串传递 ID

{"first":"9007199254740992","second":"9007199254740993","code":"00123"}

长 ID 与 00123 都是字符串，适合保留标识符的各位和前导零。但只改发送方可能违反接收方数字类型要求，应统一 API 与存储契约，并把类型变化与格式化分开说明。

把 00123 写成 JSON 数字不是保留补零 ID 的有效办法。一旦转成 123，就无法推断原宽度。固定宽度是契约的一部分，应先决定字段是数量还是精确匹配代码。

左右各输入一个对象

{"id":9007199254740993}
{"id":9007199254740992}

左右各放一个对象，不要两行合成一个输入。确认 ID 变化，再把一侧改成带引号 ID 比较类型。保精度内部表示可能显示 value 等辅助路径，不能当成 API 原字段。

1 与 1.0 数学值相同但写法不同，结构差异报告取决于比较规则。若要求精确 ID 文本，仅数值相等不够，应同时检查固定字符串与 JSON 类型。

CSV 可含正确数字，但表格软件可能读成不精确数值。其他格式转换的支持范围也不同于 JSON 整形。应逐步用虚构边界值测试，不能把一个工具的保证扩展到整个流程。

已舍入的普通数字再转 BigInt 也无法恢复尾数。两个原值合成一个后，输出无法判断来源，恢复需要舍入前数据。应修正入口而非手改显示 ID。

除 123 外，还测相邻大数、字符串大 ID、前导零代码。数字字段应注明上限与拒绝范围。全部改字符串并非通用答案，参与运算的数量可能必须是数值，应按字段语义选择。

共享时同时给出原 JSON、操作、结果和预期类型。“丢精度”不能区分显示截断与存储变化。若仅标签缩略，应检查显示层。具体观察能帮助找准修复位置。