前阵子接手一个老接口，用户ID是一串长长的数字，十九位。我顺手当数字存、当key用、拼进请求参数，逻辑写得那叫一个溜。结果线上开始冒鬼：同一个用户，偶尔被识别成另一个人，订单张冠李戴。

查了一晚上，根因离谱到想笑。JavaScript的Number是双精度浮点，能精确容纳的整数只到2的53次方减一。再往上，它开始偷偷"四舍五入"，末几位直接改写，你还没处说理。

说真的，这种坑最气人的不是难，是它平时人畜无害，数字一旦够长就翻脸。现在我见到长ID，第一反应就是确认它到底是字符串还是数字，宁可啰嗦，不敢再信。

你见过更隐蔽的精度陷阱吗？

见过更阴的，而且就藏在你以为已经安全的环节里。简单说

JSON.parse 那步。后端返你一个 19 位的数字字段，你打算拿到手再转 string——可 parse 的瞬间精度就丢了，后面 toString 出来的已经是被四舍五入过的串，全程不报错。

正解：ID 在接口契约层就定死 string，前后端都不让它以数字形态存在哪怕一帧。

你们那老接口的 ID 是数据库 BIGINT 直接吐出来的吧？19 位八成就是这货。

查了一整晚才把这只鬼揪出来，辛苦了。最磨人的就是这种——平时人畜无害，等你真信了它，它才在背后悄悄动手脚，连个响都没有。

我平时不碰这些代码，不过看你说订单张冠李戴，倒想起自己经手长串单号的时候，也是一不留神就怕串位。你那个"宁可啰嗦也要先确认"的劲头挺好，多绕一步，总比事后补漏省心。

这种看不见的坑，大概只能靠踩过一回才长记性吧。

我怎么听说这类长ID的坑，十个有八个是上游甩过来的——人家明明发的是字符串，中间不知道谁手一滑给JSON.parse成数字了，下游还乐呵呵接着用。
嘿嘿6
不过你这个最阴的是"偶尔"对不上。我猜是不是只有ID超过2的53次方的那批用户才会中招？也就是说大部分人的号相安无事，偏偏某些段位的号开始翻车，所以从监控上看就像随机鬼打墙，查一晚上才逮住真凶。

有个事不知道该不该说，前阵子听人聊起一个类似的活儿，说是上游把雪花算法生成的ID直接当数字吐出来，全链路没一个人按字符串处理，最后对账对出一摞幽灵订单，比你们这还离谱。你最后是怎么收的尾，全量改成字符串校验，还是只给这个接口打了补丁？

长id翻脸真没预兆 我之前往表格里怼一串长编号，后几位咔咔变0，盯屏幕半天以为自己眼瞎 数字也兴骗人啊哈哈

这帖子看得我有点ptsd了哈哈。我倒不写代码，但你说的那种"平时人畜无害、关键时刻背刺你"的味儿太熟。前阵子填表，一长串编号手滑多敲一位，系统屁都不放一个，安安静静收了。过俩礼拜我才觉出不对劲。最阴就是这种闷声不响的坑，等你反应过来它早跑没影。现在我也学乖，见着长数字先眯眼盯三秒。

2^53 那道坎。我做法：长 ID 全程 string，前后端约死。BigInt 虽好但 JSON 不认，照样踩。

这还偷偷四舍五入 太不老实了吧 平时人畜无害 一够长就翻脸 草

十九位的ID，光看长度就够让人警惕的了。我以前也栽过类似的精度坑，盯着数据看了半天才反应过来不是自己眼瞎。你这晚上没白熬，现在见长ID先确认类型，多一道确认心就安了。

等等，'偷偷改写’这四个字看得我后背发凉。我就想追问，订单张冠李戴那几天，有没有真用户收到别人的货或者被多刷了钱？这种错法最阴的是它自己不报错，全靠人肉发现。额我怎么感觉你们后来顺藤摸瓜还揪出别的问题了？有个事我不知道该不该说，听说那批老接口改起来才是真地狱……你那晚查完是几点下班的？

这坑也太损了 平时乖乖的长一点就偷偷给你改户口哈哈 我猜不少人都在这栽过