前两天帮朋友看个诡异问题！数据库里订单号 1523728471234567890，前端一点开详情页，id 直接变成 1523728471234567800，最后几位整个飘了。俩人盯着日志对着念，差点怀疑人生，以为哪步被注入了。

查了半天才回过味来：JSON 里的大整数在 JS 里会被当成 Number 解析，双精度浮点就 53 位有效数字，超出直接四舍五入截断。后端雪花算法吐出来的 19 位 id，前端 JSON.parse 一接，低位直接蒸发。稳，这坑踩得明明白白！

解法不难，让后端把 id 当字符串返回就完事，或者前端接个 bigint 库处理。牛啊说真的，数字明明是对的，隔着一层 JSON 就被偷偷改掉，这种背刺感真够呛。

隔着层json数字就被偷偷改了，这背刺感我服了。换我得对着屏幕愣半天 (´･_･`)

低位直接蒸发也太离谱了哈哈 数字自己偷偷减肥我是真没想到

这背刺感太真实 我也被悄悄改过一回 数字明明写对了自己就飘了

1523728471234567800 这串看着就替它委屈，好端端被四舍五入蒸发了尾巴。背刺感拉满哈哈哈

补一个坑：前端单独接 bigint 库救不回来。问题出在 JSON.parse 这一步，它先按 Number 解析，低位截断已经发生，等你拿到手再 new BigInt 也是截断后的值。得换支持大数的 JSON 解析器（比如 json-bigint），在 parse 阶段就把超长数字保成字符串或 BigInt。

最稳的还是后端直接吐 string，顺带把网关、缓存这些中间环节误转 number 的隐患一起堵了。

1523728471234567800 这结尾几个零，看着就别扭。怎么说呢
有一说一
以前帮人瞧过一回类似的，源头那头明明是对的，过一道手就悄悄走样，盯着屏幕的人还在反复确认自己没碰过。这种 quiet 的错最磨人，它不报错，就闷声给你改了。

说到底是个 trust 的问题。你当 JSON 老老实实把东西递过来，它其实早按自己的规则先处理了一遍。后端直接吐字符串是最 clean 的解法，见过有人非要在前端硬刚 bigint，兼容、精度来回折腾，最后还是绕回原点。

隔着一层 JSON，确凿便成了近似。这类事总在最被信赖的接缝处发生，无声无息…，待你察觉，末尾几位早已飘去了别处。

低位直接蒸发还不报错，这比炸个error瘆人多了

低位悄悄蒸发这背刺够损的。我当年也中过招…，对着俩对不上的数字怀疑人生

补一个边界值：JS 的 Number 安全整数上限是 2^53 - 1 = 9007199254740991，16 位。你们那个 19 位 id 直接超了三档，丢的不止一两位，是整段尾数被四舍五入截断。

顺手纠正下你说的 “bigint 库”：原生 BigInt 早有了，但 JSON.parse 不会自动给你吐 BigInt，得自己写 reviver 或者上 json-bigint 这类，否则照样翻车。

要说最稳还是后端把返回类型改成 string，前端再怎么补都是被动接招。

对着日志念了半天才发现是 JS 自己把数字偷偷改了，这画面也太真实。我当年第一次踩这坑时也是一脸问号，盯着两版 id 觉得见鬼了，后来才懂 Number 在 53 位之外就开始表演四舍五入。

楼主说的两个解法里，我其实更站“让后端吐字符串”那条。前端再挂 bigint 库总归是给自己加活儿，等于快递到了还得你自己扛秤。能跟后端扯明白的，才是省心的赢家。