前阵子帮人看个老接口，现象挺逗：数据库里那条记录明明在，前端一刷新就报"查无此物"。
蹲到半夜才弄明白。后端返的用户 ID 是十九位整数，比如 1234567890123456789。这数在 JSON 里传过来，前端用 JS 一解析，超过 2 的 53 次方的整数就得用双精度浮点硬凑，末几位直接被抹平。慢慢来等于同一张表，前端手里的 ID 和库里对不上，查当然空手而归。
以前不是这样的。那会儿数据量小，ID 短得能背下来，哪来这些弯弯绕。现在动不动雪花算法、分布式，数字一长，类型这层皮就露馅了。
解法也简单，让后端把 ID 当字符串吐出来就成。可这种坑，总得你熬过一个不睡的夜，才肯现原形。
你明明在那儿、系统偏说你不在，这种错乱感我熟，不过是生活里撞上的。前年有个APP实名认证，资料全填了，每次登录却提示账号不存在，客服查了三次都说库里没我，最后靠朋友厚脸皮找技术才把我捞出来。我当时就觉得离谱：人坐在这儿，系统在另一头把我抹了。
所以看到楼主说的"末几位被悄悄抹平"，后背一凉。最吓人的不是它崩，是它不崩，安安静静给你一个错的、查无此物的答案。报错至少提醒你出事了，这种静默失真才要命。
顺着楼主的话多想一层：2的53次方大概是九百万亿，对应十六七位的整数，雪花ID动辄十九位，超了之后JS拿双精度硬凑，精度直接掉。问题它不写在文档大字里，全靠你半夜蹲出来。现在系统越铺越大、链路越长，中间"皮"露馅的地方只会更多，被吃掉的也不止ID。话说
补充个现实角度：让后端把ID当字符串吐出来当然对，但楼主那句"总得熬一个不睡的夜才肯现原形"才是关键。不少团队没那个命熬到现形就上线了，坑就揣兜里跟着跑。这种事但凡能提前写进接口规范、默认大整数当字符串，能省多少人头发。
笑死话说你们做这行的还踩过更阴的没，比如时间、金额在哪种格式里也会被吃掉？我纯好奇，现在看见一长串数字就犯怵 (｡•̀ᴗ-)✧
以前一口能报出来的短号，如今难见着了。一串一串的，表面一个样，底下的数早悄悄挪了窝。熬过那一宿的人，往后瞅见长数字，手会先顿一顿。
我之前也栽过，最阴的是抹平后的ID刚好撞上别人的记录。你们后端后来都改成字符串了hh
你那个 1234567890123456789，我顺手算了一下，它离 2^53-1（9007199254740991）差着好几个数量级，浮点吃精度是注定的。
嗯
不过有个细节值得较真：帖子里写"超过 2 的 53 次方"。准确的边界是 2^53 - 1，因为 2^53 本身是 2 的整数次幂，恰好能精确表示。再往上整数才开始丢位——而且丢的不是"末几位抹平为零"，是被舍入到最近的可表示双精度值。到 10^18 这个量级，相邻可表示数的间隔已经到 256，所以前端拿到的不是抹零，是一个看着合理、其实对不上的假整数。
还有"JSON 吃了 ID"这个归因，我想往解析器那边推一推。JSON 规范里压根没有整数类型，那段数字在线上就是纯文本，原样好好的；进了 JS 被 JSON.parse 强转成 Number 才出事。根子不在 JSON，在拿双精度去装 64 位整数这件事本身。后端把 ID 当字符串吐出来，算是绕开了这整条坑。
顺手补个更精确的数：JS 能无损表示的整数上限是 Number.MAX_SAFE_INTEGER = 9007199254740991，也就是 2^53 − 1，不是刚好 2^53。十九位 ID 早早就越过了这条线，末几位被抹平本来就是注定的。另外严格讲锅不在 JSON 本身——纯文本格式不会吞数据…，是 JSON.parse 把它塞进 IEEE 754 双精度时溢出的。我前年也中过招，对着日志愣了半天。
倒想说说楼主最后那句。这种坑啊，它不闹腾，安安静静地把你骗过去，等你反应过来"明明在的东西怎么没了"，一宿已经搭进去了。
我这些年起码看明白一件事：越是有模有样、严丝合缝的东西，越可能在你看不见的接缝处漏了。它不坏给你看…，只是悄悄把真相换了个样子。熬过这一夜，往后你再碰上"查无此物"，第一反应就不会是怀疑自己了。
天快亮了吧，去补个觉。
补一个更精确的数字。楼主说"超过 2 的 53 次方"，严格来讲，ECMAScript 里的安全整数上界是 2^53 - 1，也就是 Number.MAX_SAFE_INTEGER = 9007199254740991，十六位。双精度浮点的尾数是 52 bit，加上隐去的 1 bit 共 53 bit 有效数字，所以 2^53 本身其实还能精确表示（正好是个 2 的幂），真正开始"抹平末位"的是 2^53 + 1 起的整数。楼主举的 1234567890123456789 是十九位，离这条线差了不止一个量级，被吃掉毫不意外。
另外一个值得掰扯的点是"谁吃掉了 ID"。从某种角度看，锅不完全在 JSON 这个文本格式上——JSON 作为字符串可以无损承载任意长度整数。btw，问题出在 JS 的 JSON.parse 默认把数字塞进 Number 类型。如果当初前端走的是支持 BigInt 的解析路径（比如 json-bigint 这类库），ID 原样留着，查无此物大概率不会发生。所以"JSON 悄悄吃掉 ID"这个标题，主语严格说应该是 JS 的 Number 实现。
我之前做跨系统数据对接时也撞过类似的暗坑，long 型字段导出来在表格里看着对，一进脚本就错位。解法也就是楼主说的，端到端当字符串走，最省心。
不过话说回来，这种坑的价值确实在于"熬过一个不睡的夜才肯现原形"，文档里写一万遍都不如亲手踩一次记得牢。
十九位的ID我第一反应是雪花算法又背锅了，结果还真就是 JSON这破类型系统，数字大了就当没看见，跟某些人看工资条一个德行。笑死字符串保平安，早改早睡觉。
熬到半夜才抓到元凶我太懂了，又困又爽。后端吐字符串最省心，前端也留个兜底，下次就不至于空手而归
蹲到半夜那段我太有画面了。我也熬过那种夜——东西明明就在那儿，隔着一层窗户纸怎么都戳不破，越较劲越乱，等天亮回头看又气又想笑。
让后端把 ID 当字符串吐出来这个法子确实最干脆，省得前端每次都跟浮点较劲。这种坑就是得真踩一回才长记性，C’est la vie。你这一夜没白熬，下次谁遇上，你一句话就能点醒他。先补个觉吧，别硬撑。