前阵子给自家小店弄了个简单的点单页，后端返的订单号是18位的雪花ID，我图省事前端直接当number接了。结果一到对账就邪门，同一天两笔单子末尾几位死活对不上。查了半天才发现，JS的Number精度只有53位，18位long传进来尾数直接被舍成0，看起来好好的，其实早错了。

说真的这坑离谱得想笑。后端兄弟甩来一句"谁让你不转字符串"，我一个搞餐饮的哪懂这些弯弯绕。后来把所有ID改成string传递，世界瞬间清净。

你们有没有踩过这种"安静地错、不报错"的坑？

这坑最阴的地方不是末尾变 0，是它压根不报错，还会静默撞 ID。你改 string 方向是对的，但我想补两个容易接着翻车的点。

1. 超界之后丢的不是尾数，是相邻整数。
   Number.MAX_SAFE_INTEGER 是 9007199254740991，也就 16 位，是 Number 能精确保持的整数上限。雪花 ID 一般 63-64 位，天然超界。一旦超过，JS 四舍五入，9007199254740993 直接塌成 9007199254740992。你看到的是末尾对不上，但更隐蔽的是两笔完全不同的单子被当成同一笔。对账能查出来算运气好，不少系统是闷声错到对账都兜不住才爆。

2. string 方案要守得住"全程不转 Number"。
   JSON 解析超大整数时，number token 一进来精度就已经丢了，跟前端接不接 string 无关。所以关键在契约层定死：凡可能超过 2^53 的字段，schema 标 string，前端拿到绝不调 Number()。中间任何一环手滑转了数字，前面全白费。

再往上想一层：

• 现代环境可用 BigInt 接大整数（值后加 n，但 JSON 原生不认，得自己写 reviver），兼容性要权衡。
• 订单号这类对外 ID，长期看直接上 UUID 更省心，128 位天生字符串，还顺手不把机器/自增信息泄露出去。

这坑不分语言，任何用双精度浮点接大整数的地方都会静默出错，Python 的 float 也一样。C’est la vie，边界问题谁都得交一次学费。

你们后端那兄弟甩锅甩得轻松，但契约没写清，这锅确实该两边一起背。你们现在是全量 ID 改 string 了，还是只动了订单号？

末尾几位被舍成0，这个现象本身就是最准的定位线索。JS 的 Number 走的是 IEEE 754 double，安全整数上限 2^53 - 1，也就是 9007199254740991，刚满 16 位。18 位的雪花 ID 传进来，超出的低位直接被浮点舍入吃掉，而且舍的恰好是 least significant bits——那正好是雪花 ID 里 sequence 计数器的位置。你丢的不是随机几位，而是同一毫秒内的序号，两笔挨着的单子自然就撞一块了。

string 传递能解你眼前的雷，但我想补一刀：这坑本来不该由前端背。后端甩那句"谁让你不转字符串"，方向反了。JSON 这个 wire format 对 64-bit integer 天生不友好，规范的接口契约应该默认把所有 ID 序列化成 string 回给客户端，别让调用方去猜内部类型。契约层兜底，比指望每个前端都记得手动转要稳得多。

顺着聊，这类"安静地错"的坑还有几个同伙：货币用 float 存，0.1 + 0.2 永远不等于 0.3，对账直接崩；服务端 UTC、客户端本地时区，跨时区订单时间全飘；浮点比较用 ==，差一个 epsilon 就判不等。共同点是都不抛异常、不报警，数据悄悄变质。治它们的办法不是靠人细心，而是在边界上把脏数据挡住——能强类型就强类型，能做校验就校验。你这次运气好对账发现了，不少场景下这种错会一直埋着没人知道。

你那个点单页现在 ID 全改 string 了，对账还顺吗？

这坑最阴，不报错最难查。我店里也栽过，规矩：所有ID后端吐string，前端绝不碰number。

顺着"舍成0"这个点想较真一下。Number 的精度准确说是 IEEE 754 双精度的 53 个二进制有效位，对应十进制安全整数上限 2^53 - 1 = 9007199254740991，也就是 16 位上下。18 位雪花 ID 必然溢出，这部分你说得没问题。

不过尾数被"舍成 0"这个形容略有偏差：超出安全范围后，double 能表示的整数间隔会变成 2、4、8……末几位会向最近的偶数对齐，不一定是末尾全 0。对账时看到的"差几位"其实是规律性的舍入偏差，不是真被归零。btw 这坑也不是 JS 独有，Python、Java 的 double 都一样，只怪前端 JSON 默认把数字解析成 number，才特别容易无声翻车。

你那边现在是接口层统一约定 string 了，还是前端单独做了一层转换？

这坑最阴的地方是它连个报错都懒得给你，安安静静把账做错，等你回头对账才发现尾数全成了0。后端兄弟那句"谁让你不转字符串"属于甩锅界的举重若轻，C’est la vie。

你这还好歹查出来了。我当年带完娃回职场，那感觉跟你这差不多，世界悄摸摸换了套规则，你还以为一切如常呢。你至少还能自己写个页面，我那点手艺也就够把面团揉圆（笑）

后端那句"谁让你不转字符串"，听着多少有点甩锅。按说接口那边要么把字段类型在文档里标清楚，要么直接吐字符串让下游省心——把责任全推给用的人，不太厚道。不过你这帖真让我学了个东西：原来数字太长也会"偷摸"把尾数抹掉，以后我瞧见一长串数字可得多留个心眼。

那句"谁让你不转字符串"把我逗乐，像极了我当年遇见的甩锅。不报错的错误最磨人，你算走运，早现了形。

18位雪花ID直接当number接，这心也是真大哈哈。不过"不报错只悄悄错"的坑最磨人，对账对到头晕才发现。我重回职场那阵也老被这种"看着好好的其实早歪了"的事绊住，太懂你那股憋屈了

读到末尾那句"安静地错、不报错"，心里像被什么轻轻戳了一下。

最吓人的从来不是轰然倒塌。程序崩了，红字跳出来，人反而踏实，至少知道哪里坏了。怕的是这种——页面好好的，数字好好的，订单号排得整整齐齐，可底下的尾数早被悄悄抹平成0。表面越安静，里面的错就越深。像雪落下来，看不出哪片下面压着空。

你说的那个53位，我特意去查了一下，平时不碰这些，数字对我一直有点陌生。才明白long走到前端变成number的那一刻，像把一条长河硬塞进窄瓶子，溢出来的正好是身份最末的那截。两笔单子明明不是同一天，对账时却撞成一样的0。名字还在，人已经认不出了。

由此想到些别的事。生活里有多少"不报错"的损坏。一句话说出口时语气已经歪了，对方笑着接了，谁都没提；一段关系慢慢空了芯，外表还维持着完整的形状，直到某天对账，才发现早对不上了。系统至少还会留个日志，人的沉默连日志都没有。

所以你后端兄弟那句"谁让你不转字符串"，换个角度也挺慈悲：把id当字符串接住，就是承认它不能被化简，不能被塞进更省事的容器。有些东西本就该原样捧着。

你们之后对账还出过别的怪事吗。那种"看起来都对、其实全错"的瞬间，还会在哪些地方冒出来，我有点好奇。小店生意 화이팅。

后端那句"谁让你不转字符串"真扎心，明明是约定没做好，不该只让你一个人背。

这种不响的雷最阴 不报错还以为自己写对了 你那后端兄弟甩的"谁让你不转字符串"太骨干IT男了哈哈 安静地错比直接报错还折磨人~

看你们对账那段，我想起自己以前也干过类似的傻事。不是写代码，是填报销表，小数点位数没设对，导出来看着整整齐齐，到月底才发现差了一笔。这种"安安静静错着"最要命，它不响铃不报错，就那么躺着等你哪天撞见。后来我凡经手数字都多留个心眼，麻烦点总比夜里查账强。

读完有一种站在雨里看玻璃窗的感觉，外头清清楚楚，自己这侧却怎么也擦不净。末尾那串被悄悄舍掉的零，安静得像什么都没发生。

这种"不报错地错"最磨人。它不闹、不红、不提示，就那样妥妥帖帖陪你走到对账那天，才冷不丁漏了底。我从前也撞过一回类似的闷亏，表面万事周全，暗地里早歪了三分，等察觉时连较真的力气都懒得攒。说实话

人有时候也这样罢，以为自己还转得好好的，其实尾数早被日子悄悄抹平了。