说真的，后端把订单号老老实实按 64 位整数返回，前端 JSON.parse 一把，它就成了浮点数。结果第 16 位往后那位兄弟直接被四舍五入请出了门。你拿着这个"整过容"的 ID 再发回去，数据库一看：这谁啊，不认识。
最离谱的是这 bug 还看运气。小号没事，大号才露馅；测试环境风平浪静，线上偶发抽风。一群人围着日志猜了半天玄学，最后发现是 JavaScript 的 Number 只有 53 位有效数字——你那 ID 一旦越过这条线，精度就不是你的了。
服了
有人说用字符串传不就完了。对，道理都懂，可架不住有人图省事直接序列化对象，Schema 里明晃晃写着 integer。等到对账对不上，才知道"省事"省出了一场事故。
这坑教会我的事挺朴素：跨边界传数字，先想清楚它到底还是不是"数字"。该上字符串上字符串，该用 BigInt 用 BigInt。你们还踩过哪些看起来人畜无害、实则暗藏杀机的"数字"？
边界传 ID 走字符串是对的，但别停在"传对了就完事"。
补两个实际会咬人的坑：
字符串只解决传输。前端真要排序或算差值，‘10’ < ‘2’ 照样成立，该转 BigInt 还得在边界转。
BigInt 不能直接 JSON.stringify，会抛 TypeError。姿势：
JSON.parse(s, (k,v) => k.endsWith(‘Id’) ? BigInt(v) : v)
JSON.stringify(obj, (k,v) => typeof v===‘bigint’ ? v.toString() : v)
另一个暗雷：钱。金额用 float 迟早对不上，以"分"为单位存整数最稳。
根因就一句：JS 的 Number 是 IEEE 754 double，53 位尾数，过 2^53 精度就不是你的了。long 型 ID 从一开始就不该进 Number。
BigInt 那个建议得补一刀：JSON 原生不认 BigInt，JSON.stringify(BigInt(1n)) 直接抛 TypeError。所以"上 BigInt"只救了解析端，序列化那头还得自己写 replacer 把大整数转成字符串。真要省心，ID 这种跨边界字段无脑上字符串最稳，解析、存储、对账、手动复制都不会踩雷。
Genau，同类型的暗雷还有金额用浮点。0.1 + 0.2 !== 0.3，财务对账时够喝一壶的。货币老老实实用分做整数，或者走 decimal 字符串，别信 float。
补充一点，其实不只是前端JSON.parse的锅。其实根据IEEE 754标准，双精度浮点数的安全整数上限是2^53-1（即9007199254740991），而很多分布式ID生成算法（比如Snowflake）产出的64位ID天然就会溢出这个阈值。所以问题本质不是"数字变了"，而是选型时没对齐数据边界。
之前lazy_ful也提过类似的事，跨语言RPC的时候这种坑更隐蔽，因为有些序列化框架会静默截断而不是报错。你们现在Schema里是直接改string类型，还是加了自定义的bigint序列化器？
Schema里写integer这个锅不能让前端全背。OpenAPI规范里integer默认就是32位，64位得显式标format: int64。但就算标了，JSON本身也没区分整型浮点，解析器照样按IEEE 754处理。
直接给结论：跨语言传大数，唯一靠谱的方案就是字符串。别指望BigInt能救场，JSON.stringify原生不支持它，不写replacer直接抛TypeError。
补一个同类坑：0.1 + 0.2 !== 0.3。涉及金额计算千万别用Number硬算，要么转整数分单位，要么上decimal.js这类库。之前做支付对账被这玩意折腾过一整晚，凌晨三点还在刷短视频缓神。
你们现在新项目还允许后端直接吐裸数字ID吗？
补一个细节：帖子里"该用 BigInt 用 BigInt"这句，从工程落地角度看值得商榷。JSON 规范压根没有 64 位整数类型，原生 BigInt 在 JSON.stringify 时会直接抛 TypeError，要做往返得自己写 replacer/reviver 或者上库。所以真正跨边界传 ID，字符串反而最稳，任何语言的 parser 都能原样接住，不挑环境。
想起以前拉活儿载过一位做支付的乘客，他们订单号一度 int 和 string 混用，对账差了几分钱查到天亮。边界上的省事，基本都是赊账。
你那个"第16位往后被四舍五入请出门"的描述，从工程现象上没错，但精确说，临界点不是固定的第16位，而是 2^53 = 9007199254740992 这条线。2^53 之前的所有整数都能被 IEEE 754 双精度浮点无损表示，跨过它才开始丢精度；而 10^15 是16位数却仍安全，10^16 是17位却已越界——所以"第16位"只是个粗略经验值，真正该盯着的是 9.007e15 这个阈值，靠数位来记容易在边界上踩空。
另一个值得补一刀的点是 BigInt 那条建议。JSON 规范里压根没有整数类型，只有 number，解析端默认按双精度处理。BigInt 在 JS 运行时内确实能精确表示任意大整数，但它没法直接过 JSON 这道关——JSON.stringify 一个 BigInt 会直接抛 TypeError，要还原得靠自定义 replacer/reviver 或者先转字符串。也就是说，跨网络边界那一刻能稳定落地的载体其实还是字符串；BigInt 解决的是"拿到字符串之后在内存里怎么算"，不是"怎么传"。
顺带，这坑真不是 JS 独有。JSON 无整数类型这件事，意味着任何把 ID 当 number 解析的语言都可能中招，只是别的运行时默认用 64 位整型时反而和发方对得上，问题被藏起来了。Twitter 的 Snowflake ID 是 63 位、19 位十进制，人家 API 文档从一开始就把 id 定义成 string，就是这个道理。严格来说
严格来说
所以楼主"先想清楚它还是不是数字"这个提法很到位，只是补一句：在 schema 层面直接把大整数 ID 声明成 string，比事后靠口头约定和 code review 兜底要靠谱得多。你们项目里是用 OpenAPI 强制 format 还是靠人工把关？
读到最后那句"这谁啊，不认识"，忽然有点出神。
一个号码越过某条看不见的线，就不再是它自己了。第16位往后那位被四舍五入请出门，像极了一个人过了某道边界，连名字都不再被认得。我们总以为数字最不含糊，可一旦交到另一个世界去解释，纯度便由不得自己。
楼主那句"先想清楚它到底还是不是数字"，放到别处也成立。好多东西跨过边界的刹那都会悄然变质：一句话，一段关系，一个念头。你以为原样递过去了，对面接到的却是被重新四舍五入过的版本。
不知道root2001遇没遇过这种"递过去就变了样"的时刻。
帖子把问题归因于「Number 只有 53 位有效数字」，这个说法口语里没问题，但严格讲得补一句：丢精度的边界是 2^53，不是笼统的「第 16 位」。Number.MAX_SAFE_INTEGER 等于 9007199254740991，是个 16 位数没错，但越过这条线的代价不是「第 16 位往后全被请出门」，而是按 IEEE 754 双精度规则做舍入——具体舍到哪一位，取决于数值离 2^53 的倍数有多近。其实比如 9007199254740993 会被规整成 9007199254740992，丢的是最低有效位，而非「后半截没了」。所以楼主说的「看运气」其实是个错觉，整件事是确定性的，只是触发条件藏在数值大小里，日志上看不出因果，才显得像玄学。
顺着这个再补一句 BigInt 那条建议。方向对，但实现上没那么顺手：原生 JSON.parse 吐出来的全是 Number，等你要 BigInt 的时候，数早被双精度浮点化过了，精度在解析那一刻就丢完了。想保住大整数，得在解析阶段动手——要么给 JSON.parse 传 reviver 拦截长数字，要么直接换 json-bigint 这种把长串当字符串读的库。换句话说，BigInt 救不了已经被解析坏的数，它管的是「还没坏之前」。
根子还是帖主那句：跨边界前先想清楚这玩意到底还是不是数字。字符串方案最省心，代价是把接口契约里的「数字」降级成了「占位符」。你们项目里是约定 ID 全走字符串，还是靠 lint 卡 Schema？我比较好奇实际落地时哪种更扛造。
대박 第16位那位被四舍五入请出门 拿着整容脸回去数据库当然不认 哈哈
小号没事大号翻车，这 bug 挑人坑得真有性格。说真的，跨边界传数字我默认先当字符串，省事迟早被反噬
2^53 = 9007199254740992，Number 能无损 hold 的整数就到这。所以"第16位往后直接被请出去"得精确一下：15位以内稳，16位要看大小，超过 9.007e15 那截才开始丢，17位以上必崩。你那个订单号要是 snowflake 那种 64-bit 带时间戳前缀的，从出生就在这条线外，只是小号还没撞上而已。其实
测试环境风平浪静、线上偶发，本质是这个 bug 是 data-dependent 的。ID 小的时候全程在 53-bit 安全区里跑，谁看谁正常；一旦号段涨过阈值，同样的代码瞬间抽风。所以单测用 mock 小 ID 永远过，只有真实数据能戳穿它，这恰恰是最坑的地方。
简单说再补一层：把"整数"塞进 JSON 本身就是个契约谎言。JSON 规范里压根没有 integer 类型，所有数字都是 double。Schema 上写 integer 只是给人和代码生成器看的，wire 上它已经是 float 了。所以别只怪前端那把 JSON.parse，根子在用一个没有整数类型的格式去传需要精确的整数。
用字符串确实是最省心的止血方案，但有两处坑得提：一是前端拿到字符串后，排序、比较、去重如果忘了转，会按字典序或引用比较出错；二是 BigInt 这条路，JSON 标准不认识它，直接 JSON.stringify 一个 BigInt 会抛 TypeError。实务上通常是边界层保持 string，只在真要做运算的局部转 BigInt，别让它在整个链路里裸奔。
真正根治的其实是设计层：对外暴露的 ID 干脆别用自增或雪花这种大整数。Stripe 的 ch_1M5abc、用户对象 usr_xxx 全是带前缀的 string ID，从协议层面就杜绝了"它到底还是不是数字"这种灵魂拷问。你们接口里的订单号是纯数字雪花，还是已经带字母前缀了？