在互联网应用开发中，前后端联调时常上演“数据对不上”的拉锯战。最近，一个看似不起眼的 Bug——JSON.parse 大数精度丢失——成了不少团队调试的噩梦，更让前后端工程师陷入互相指责的尴尬境地。这个问题的本质，其实源自 JavaScript 与 JSON 规范之间的“历史遗留矛盾”。
问题重现：数字“凭空”变了样
假设后端返回如下 JSON：
{"id": 12345678901234567890}
前端使用 JSON.parse(jsonString) 解析后，打印出的 id 却变成了 12345678901234567000。前后差异巨大，后端坚称“我传的就是这个数”，前端却看到数据被“篡改”。类似场景在涉及大整数 ID（如雪花算法生成的 64 位 ID、微信支付订单号等）时频繁出现。
更令人头疼的是，这个 Bug不会抛异常，只是静默地更改了数值——前端代码逻辑依然正常执行，只是计算出的结果完全错误。这种隐蔽性让调试变得极其困难，往往排查数小时才能定位到根因。
技术根源：JavaScript 的“数字天花板”
问题的根源在于 JavaScript 的 Number 类型采用 64 位双精度浮点数（IEEE 754 标准），能精确表示的整数范围仅为 [-2^53, 2^53]（约 16 位十进制数字）。当 JSON.parse 遇到超过此范围的整数，会将其转换为浮点数表示，导致低精度位被截断。
JSON 标准本身并未规定数字的整数边界，RFC 7159 明确指出“数字的精度无限制”。然而，几乎所有主流编程语言（Python、Java、Go 等）的 JSON 解析器都默认将数字解析为原语言中的浮点类型——JavaScript 的浮点数精度限制就成了这最后一环的瓶颈。
甩锅现场：谁也“不背锅”
前端工程师的理由很充分：“我收到的是正确的 JSON 字符串，但 JSON.parse 解析出的对象里数字就是错的，这是浏览器/Node.js 引擎的缺陷。”后端工程师反驳：“我序列化时字段数值完全正确，数据库里也存得好好的，数据经过网络传输未改变，凭什么说我的数据有问题？”
双方各执一词，但问题确实不属于任何一方的直接过错：后端确实发送了合法 JSON，前端也确实执行了标准解析——错的是“在不适合的场景使用了 JSON 的默认数字类型”。更棘手的是，如果前后端由不同团队开发，这种责任模糊性极易演变成跨部门的沟通内耗。
解决之道：让数字“说话”更安全
-
字符串传输大数
最直接、最可靠的方式：后端将超长整数强制转换为字符串传递，前端再通过BigInt或字符串工具函数处理。例如返回{"id": "12345678901234567890"}。缺点是接口设计需做出改变，且可能导致现有系统改造工作量较大。 -
使用 BigInt 原生支持
较新的浏览器引擎支持JSON.parse的第二个参数接收一个reviver函数，可在解析时识别大数字并转换为BigInt。但需注意，BigInt不能与普通 Number 混合运算，输出为字符串时也可能改变格式。 -
替换解析库
社区已有成熟解决方案，如json-bigint（npm 包），它能自动将超出安全范围的整数解析为BigInt对象，避免精度丢失。适用于需要保留大整数的场景，但会增加项目依赖和运行开销。 -
约定前端精度
如果业务确认不会超过 JavaScript 安全整数范围，可双方约定所有数字字段限长在 15 位以内。但这属治标不治本，且限制了业务发展空间。
行业启示：规范与实现的博弈
这个 Bug 揭示了 Web 开发中一个尴尬的现实：广泛使用的协议（JSON）与运行平台（JavaScript）之间存在历史遗留的数值精度鸿沟。类似问题同样出现在 Python 的 json 模块、Java 的 Gson 等库中，只不过 JavaScript 的前端角色让其表现最为突出。
随着微服务架构普及和全栈开发模式兴起，前后端工程师更需建立“数据契约意识”：对于关键字段（ID、金额、时间戳），应在 API 文档中明确标注类型约束，并主动在两端设置值域校验。与其互相甩锅，不如共同认可“默认解析不可靠”这一事实，在系统设计阶段就为大数问题留好退路。
对于团队管理者，这个 Bug 也是一面镜子：当“锅”飞来飞去时，最该补充的不是人手，而是技术规范的共识与测试用例的完整性。否则，下一次“精度丢失”换一个名字，还是会卷土重来。