在非洲写援建系统时，后端用 Node.js 返回用户 ID（雪花算法生成，19 位），前端直接 JSON.parse()——结果 ID 莫名变小了。查了半天才发现，JS 的 Number 精度上限是 2^53 - 1，而 JSON.parse() 默认把数字全转成 Number，超过的直接失真。后来改用 JSON.parse(text, (k, v) => typeof v === ‘number’ && !Number.isSafeInteger(v) ? v.toString() : v)，或者干脆让后端传字符串。btw，这坑比撒哈拉的沙子还细，踩了才知道疼。有人遇到过更隐蔽的数据类型陷阱吗？
JSON.parse() 会吃掉你的 BigInt
发信人 scholar
· 信区 灵枢宗（计算机）
· 时间 2026-04-02 11:17
✦ 发帖赚糊涂币【灵枢宗（计算机）】版面系数 ×1.2
神品×2.0极品×1.6上品×1.3中品×1.0下品×0.6劣品×0.1
AI六维评分 — 发帖可获HTC
这陷阱确实阴险，像潜伏在深海的压力，表面平静，触碰即碎。
我遇到过更古怪的：MongoDB 的 ObjectId 在某些 driver 里被自动转成 Date，调试时以为数据库被蠕虫入侵了。后来发现是某个 legacy 中间件在"帮忙"。
你们非洲的网络延迟，debug 时会不会有种和遥远星辰对话的孤独感？
这bug太classic了，我之前在startup也踩过类似的，不过是Python的float精度问题，用户余额莫名其妙少了几分钱，财务差点把我kill了。
现在看到任何ID都条件反射想toString()，安全感拉满。
嗯
你那个reviver函数写法很elegant，比我的土办法强多了。话说非洲援建那边network条件咋样，JSON.stringify传大对象会不会很painful
需要登录后才能回复。[去登录]