问题场景

某天上线后运营反馈："使用者详情页打开后跳转到其他页面时 ID 不对，每次点进去都是另一个人。"

排查发现，后端返回的 JSON 如下：

{ "userId": 12345678901234567890。"name": "张三"}

前端用 JSON.parse 解析后userId 的值变成了：

const data = JSON.parse;console.log，// 输出：12345678901234567168

最终几位全变了。 跳转时拿这个错误的 ID 去请求，自然查到了另一个人。

最坑的是——这个 Bug 不是必现的。想要会触发，小 ID 完全正常。导致开发环境测不出来，必须 ID 超过一定位数。怎么说呢，

原因分析

JavaScript 的数字限制

JavaScript 所有数字都遵循 IEEE 754 双精度浮点数标准。它能安全表示的整数范围是：

- ~ 9,007,199,254,740。991

超过此范围时JS 会做舍入处理：

const big = 90071992547409917;console.log，// 输出：90071992547409920

You can verify with Number.isSafeInteger

Number.isSafeInteger;// false

JSON.parse 的静默丢失

JSON.parse 在解析大整数时不会报错。只会返回已被舍入后的数字，没有任何警告或异常。这正是导致难以排查的根源：

const json = '{"id":90071992547409917}';const obj = JSON.parse;console.log，老实说，// 90071992547409920
// 没有异常、没有 console.warn

谁的锅？

Caution: 当你看到大整数在前端出现“奇怪”结果时请检查其是否超出安全整数范围，而非怀疑后端数据错误。

方位	论点	分析
后端 我数据库存的是完整 ID ✅	数据源没错 ✅	传输层无误 ✅
前端 我收到的是完整字符串 ✅	解析阶段出问题 ❌
是 JSON 与 JS Number 类型之间天然的鸿沟造成的问题，没有谁背锅。

方法

方案一的观点是。后端改为字符串返回

后端将大整数统一以字符串形式传给前端：

{ "userId": "12345678901234567890","name": "张三"}

前端无感知，直接作为字符串使用。但要注意接口文档明确标注哪些字段为字符串型 ID，以避免混用。

方案二的观点是，后端改用 Lossless JSON 库

• Java:

Java: 使用 Jackson 并添加 @JsonSerialize 注解，将字段序列化为字符串。

Go: 在结构体标签中使用 json:"userId,string" 指定该字段为字符串。

Node.js: 使用 lossless-json 或类似库，在序列化时保持数值完整性。

这类库在后台序列化时就把大整数转成可安全传输的数据格式，从而避免 JS 整数溢出。

如果你无法修改返回格式，可以考虑以下两种策略： 1️⃣ 前端在接收之前先将所有可能的大整数转换为字符串；2️⃣ 后台在序列化之前做一次预检查，如果检测到超出范围则自动转换。

这两种方法都能确保前端拿到的是 准确且可读 的 ID。

再看请记住，如果你想保持业务逻辑上的“整型”。就必须让前后都支持 BigInt 或者通过协议层保证传输类型一致。否则就像上面一样只会悄悄丢失精度。按理说，

The above content includes placeholder for actual code examples that would be rendered by a Markdown-to-HTML converter with syntax highlighting support .

---