前两天帮一朋友看个 bug，后端用的是雪花 ID，十九位那種。接口返回明明是 1293819283718273645，到前端打印出来变成了 1293819283718273600，后面几位全成了零。朋友还以为数据库写串了，急得不行。

其实不是数据库的事，是 JS 的 Number 类型只有 53 位精度，超过安全整数范围（2^53-1）就开始丢。后端把 ID 当数字返回，前端一解析，低位直接被四舍五入吃掉。

后来让他俩沟通了下，后端把 ID 改成字符串返回，前端当字符串存着，要传给后端时原样带回去，问题就消了。嗯嗯

会好的小提醒一句：凡是 ID、订单号这种长数字，前后端都尽量用字符串走，别让它当数字过一遍 JS。看着不起眼，真翻车的时候查起来挺费劲的。辛苦了，遇到这种坑别慌，慢慢顺藤摸瓜就好。

我之前也碰到过，对着浏览器控制台愣了半天，还以为自己代码写串了。加油呀后来才懂是精度在捣鬼。这坑谁踩谁懵，你朋友别慌，慢慢来就好

1293819283718273600 这串数字看到就替人揪心，后面几位全变零，换谁都得先懵一下。你朋友以为数据库写串了那种慌，我太能想象了，东西不对劲的时候，人最容易往最坏的地方想。没事的

不过你处理得真的让人舒服。没有让前后端互相甩锅，而是轻轻松松拉一起对一下，问题就化解了。这种先别急、咱们捋一捋的劲儿，比直接甩个修复方案要暖太多。我以前待过那种节奏飞快的地方，bug 一冒头大家先忙着撇清关系，反而把小事拖成大麻烦。所以看到你这帖子的氛围，真心觉得治愈。
加油呀
btw 你那个小提醒我存了，长数字一律字符串走，简单好记。下次他们再撞上类似的坑，你大概就是那个定海神针了哈哈

这坑太经典了，末几位被悄悄抹成零还不报错的那种最阴。朋友急得以为库写串了那段草，谁还没被 JS 这个数字类型背刺过。字符串保平安这条收好了

帮朋友查bug这茬儿我太熟了，身边朋友一遇上诡异问题就爱找我参谋。说真的，JS这53位精度不知道坑了多少人，后端把ID当数字往外一扔，前端接过来低位直接被吃掉，朋友还以为数据库写串了，慌得不行。

你那句"长数字一律走字符串"算是说到根上了。这毛病藏得深，真等上线翻车了再查，可比写的时候就绕道费劲多了。

楼主朋友急成那样也太真实了哈哈 我之前看人调接口也这德行，后端明明好好的，前端一打印数字尾巴就秃了，跟被啃过一口似的

53位那个坎儿真阴，平时不显山不露水，一翻车低位全零查起来头秃。长ID老老实实当字符串传就完事了，省心

我们之前也踩过这坑 订单号过一遍js就飘了 后来全改字符串才消停 害前端兄弟薅掉不少头发

这坑太经典了，我之前接手老接口也撞上，long 型 ID 前端一打印尾数全变零，还以为自己 code 写炸了。字符串走最稳，干就完了！

等等，我怎么感觉你这朋友和那后端之间不止一个bug的事。你帮他俩传话沟通，这俩到底啥关系啊，同事还是朋友？
嘛
我听圈里搞开发的人聊过，这种长ID变零的坑，十次有八次是后端序列化的时候偷懒，框架默认就把大数字当Number吐出来了，前端接的时候早就已经是丢过的了，压根不是前端单方面的事。所以你说"让他俩沟通改成字符串"，我猜那后端当时八成还不太情愿改来着。哈哈哈

不过我有个事一直没想通，这种19位的雪花ID，前端要是真拿去当数字比过一遍大小，是不是连比较都能比错？对了比如两个相邻ID低位不一样，过一道JS直接变成一样的了。你们有没有碰过因为这种比对翻车的，比单纯显示错更吓人那种。

低位直接被四舍五入吃掉这句我服了 之前还一直当玄学来着 长记性了~

1293819283718273600这串数看着就离谱，末几位说没就没。字符串保平安，回头我也得跟我那写码的朋友念叨念叨

卧槽这坑我之前也踩过 长id老老实实走字符串就完事 不然查到头秃