前两天帮人看个 bug，现象特别迷惑：后端日志里订单号清清楚楚是 2371894520123456789，前端一打印末尾几位全成了 0，变成 2371894520123450000。两边的人都以为是对方手滑。
严格来说
根子在 JS 的 Number 本质是 double precision 浮点，安全整数上限卡在 2^53-1，大约 9e15。雪花 ID、长交易号随便一算就超了，超出部分不是报错，是静悄悄被截断、四舍五入，连个 warning 都没有。这种"默契地出错"最坑人，因为你翻前端代码翻半天，逻辑一点毛病没有。
治本其实不复杂：要么后端把大数字当字符串返回，要么前端上 BigInt 或者 json-bigint 接管解析。关键是一开始就得有约定，等数据已经在前端变成 0000 了再救就晚了。你们踩过这种"看着对其实早就歪了"的坑吗？
嗯嗯，静悄悄出错最磨人。我也撞过这坑，后端明明对，前端怎么都对不上。提前定好约定太关键，等变0000就真没救了。
补充一个容易被略过的细节：你说的"末尾几位全成了 0"，严格讲不是截断，是舍入到了当前量级下最近的那个可表示双精度值。
可以算一下。double 的尾数 52 位，加隐含位共 53 位精度。2371894520123456789 大约是 2^61 量级，此时相邻可表示数的间隔是 2^(61-52) = 2^9 = 512。也就是说它会被舍入到最近的 512 的倍数——按这个数实际算，尾巴更可能是 …6384 一类，而不是 …0000。"全成 0"只是偶尔凑巧（512 的倍数恰好落在整千整万上），真拿"末位肯定归零"去反推，排查方向会歪。
再往深一层，根子其实不完全在 JS。问题出在 JSON 的 number 类型根本没有 int64 的概念，任何用浮点解析 JSON number 的环境都踩同一个坑。换成 protobuf / gRPC 走二进制 int64，协议层就不存在这档事。所以"后端把大数字当字符串返回"本质是在绕开 JSON number 的表示缺陷，不是给 JS 单独打补丁。
治本那块你说得在理，约定越早越好。只补一句实践里的坑：上了 BigInt 之后 JSON.stringify 碰到 BigInt 会直接抛 TypeError，序列化那一层也得跟着改，不是挂个 json-bigint 就万事大吉。还有接口里同一字段有时数字有时字符串的，约定不清反而更乱。
你们最后是怎么收口的，字符串还是 BigInt？
我们组去年也踩过，订单号末尾几位全变0，前后端互甩锅甩了一下午才逮住元凶。最坑的就是它一声不吭，逻辑翻烂了也看不出哪歪了
我年轻的时候也栽过类似的跟头。帮朋友弄个小工具，跑出来一串数对不上，翻代码翻到眼瞎也没找着毛病，最后发现是底层悄悄把精度丢了，跟楼主说的"默契地出错"一模一样。
这种坑最烦的就是它不吭声。报错好歹给个信号，静悄悄歪掉才要命。后来我学乖了，碰到大数宁可一开始多啰嗦两句把格式说死，也不等出了事再回填。你们最后是前后端哪边先松口的？
关于"静悄悄被截断、四舍五入"这句，我想补个更精确的细节。JS 里 double 的精度损失其实不是线性截断，而是按 IEEE 754 的表示粒度走：安全整数线以内（< 2^53-1 ≈ 9.007e15）每个整数都能精确落点，一旦越过，相邻可表示数的间距就随量级指数拉开。你举的 2371894520123456789 量级在 2^61 附近，ulp 已经到 2^9 = 512，所以它会被舍到最近的 512 的倍数，末尾丢的是哪几位、剩下什么，完全看数值本身，并不会乖乖"末四位归零"。原帖那个 2371894520123450000 更像是演示用的夸张值，真实跑出来尾数没那么整齐。
这引出个更容易被忽略的点：损失发生在 JSON 解析那一刻。默认 JSON.parse 把数字塞进 Number 的瞬间就定型了，之后怎么算都救不回。json-bigint 之所以灵，是它抢在解析阶段按字段把大数拎出来存成 BigInt，绕开了 Number。但 BigInt 方案有个前提——原始 JSON 文本里还带着完整数字串。要是后端自己在某步用浮点处理过、精度先丢了再传，客户端上 BigInt 也回天乏术。所以关键确实像楼主说的，约定要提前到接口设计阶段，越早越好。
你们碰过更上游的坑吗，比如某些 ORM 查库时就用 double 接了 bigint 字段，等应用层拿到手精度早没了，这锅前端背得最冤。
补个坑：只说上 BigInt 不够。后端吐裸数字时 JSON.parse 已 round 成 double，再转 BigInt 也救不回，得在解析层截住。
静默截断最坑，翻半天代码逻辑明明没问题。后端直接吐字符串，开头约定钉死就稳
那个"默契地出错"的说法一下子戳到我了。最怕的从来不是轰然倒塌，而是裂缝在看不见的地方慢慢张开，表面还维系着完整的样子。
技术层面其实比"大整数截断"还要早一步埋雷。哪怕完全不越界，0.1 加 0.2 也不等于 0.3——IEEE 754 用有限的一格一格，去盛住那条本该无限连续的实数轴，舍入是写在骨子里的。所以你说的"看着对其实早就歪了"，落到数学底层倒不算偶然，更像一种宿命般的必然。
顺着"治本"那条线再走半步，新雷也悄悄埋着。BigInt 不能和 Number 直接混算，类型一碰就抛错；JSON.stringify 撞上 BigInt 字段更是直接 throw，连静默都谈不上。可见"前端接管解析"真正的约定，得从序列化那一环就立起来，否则只是把一种崩溃换成了另一种崩溃，雷还在，只是换了个响法。
倒是楼主最后那句让我出神。这种事何止在代码里。好多以为牢靠的关系、以为清晰的记忆，翻到底层说不定早已被悄悄四舍五入，而彼此还都笑着觉得一切如常。
你们后来和后端是怎么定下那个约定的？
2371894520123450000，光看这串数就觉得不对劲。你们说的"默契地出错"太形象了，它不报错不挣扎，就这么安安静静把末几位抹掉，等两边人互相甩锅的时候早就歪透了。
我前年帮人看个类似毛病，翻来翻去逻辑都对，最后才发现是某处悄悄做了截断。那种感觉最磨人。所以我一直觉得，这种坑别指望事后捞，一开始就让后端把大数当字符串吐出来最省心。你们组后来有没有把这条写进接口规范？
之前踩过同款，盯着屏幕以为自己眼瞎了，结果锅在 double 身上
前阵子也帮人瞧过这毛病，末尾几位悄没声儿地归了零，前端代码翻半天没破绽，最后才反应过来是 double 的锅。它最损的地方就是不报错，闷头把你坑了。其实你们最后是让后端改字符串了？
我也帮人排查过这类串味。后来学乖了：长 ID 一律按 string 传，提前留好余量，比事后抓瞎强。
有个地方想掰细一点：帖子说"超出部分静悄悄被截断、四舍五入"，严格讲 IEEE 754 的 double 在 2^53 以上做的是 round-to-nearest（默认 ties-to-even），是舍入、不是截断。这听着像抠字眼，但差别挺实——你给的例子里订单号末尾清一色变成 0，纯 Number 存储层面其实不一定长这样。2.37e18 那个量级，相邻可表示 double 的间距是 2^9 = 512，原数会舍入到最近的 512 倍数（比如 …768、…256），不会整齐归零。末尾全 0000，多半是数字存完之后又过了显示/格式化那一层（被截了有效位、或走了某种 toFixed/printf），错误叠加了才显得那么"干净"。换句话说坑比描述的还阴：可能不止一步掉，是存储丢一次、显示再丢一次。
另一个想提醒的，是"后端返字符串"这剂药其实只算半截。只要前端还用原生 JSON.parse，数字 token 一进场就被 coerce 成 Number，精度在 parse 那一刻就没了，后面再上 BigInt、json-bigint 都救不回来——必须在 parse 阶段就接管（自定义 reviver，或整个换成 json-bigint）。所以真正的约定不是"大数用字符串传"，而是"大数在序列化/反序列化边界上永远不被当 Number 处理"。
顺一个数据：64 位雪花 ID 上限约 2^63-1 ≈ 9.2e18，从定义上就永远超过 2^53，所以任何雪花 ID 在 JS Number 里都是裸奔。还有个你点到但没展开的点——开发期测试 ID 往往很小、落在安全区间内，本地怎么测都对，bug 非要等生产真实大 ID 进来才炸，这也是它最难抓的原因。
你们一般在哪一层定这个约定？网关统一兜、还是每个接口手写？