1. 一个 19 位雪花 ID怎么到浏览器就变了样1.1 那天早上我遇到的幽灵订单号事情是这样的周一刚坐下客服就转来一个工单说某个订单在后台管理系统里显示成了另一个订单号用户对不上账。我查了半天数据库订单号的原始值是7274837171504734208但是前端页面上渲染出来的却是7274837171504734000。乍一看好像只是尾数不同但对于订单系统来说一个字符不一样就是完全不同的订单。查到最后所有人都在怀疑后端接口是不是返回错了唯独没人怀疑 JavaScript 自己。问题其实出在 JavaScript 大整数的精度丢失上。7274837171504734208这个数字有 19 位而 JavaScript 的 Number 类型能保证精确表示的整数上限是2^53 - 1也就是900719925474099116 位。一旦超过这个范围数字就会四舍五入到一个最近的可表示值后面的低位被悄悄抹掉。Snowflake 雪花算法生成的分布式 ID 恰恰都是 64 位整数动辄 19 位所以只要你接触过互联网公司的订单、用户、消息这类系统几乎迟早会撞上这个坑。这篇文章我就把这个问题的前世今生彻底讲透为什么偏偏是2^53 - 1、怎么判断精度已经丢了、BigInt 应该怎么用、存量系统怎么优雅过渡。如果你平时写前端、接后端接口或者在做数据处理这篇文章应该能帮你省下好几个加班的晚上。1.2 三行代码复现这个 Bug很多人在项目里遇到这个 bug 时第一反应是后端 JS 转错了或者前端框架出 bug 了所以我建议先记住下面这个最小复现任何时间你觉得可疑都可以用这三行代码马上验证const orderId 7274837171504734208; console.log(orderId); // 7274837171504734000 console.log(orderId 7274837171504734208); // false第一行代码执行时7274837171504734208这个字面量在解析阶段就已经被转成了最近的可表示浮点数7274837171504734000所以的结果是false。更经典的版本是这个console.log(9007199254740992 9007199254740993); // true两个明明不同的整数在 JavaScript 里比较结果却是相等。这就是精度丢失最直观、最残酷的证明。没接触过的人可能会觉得JS 是不是疯了其实 JS 没疯它只是严格遵守了一个底层规范——数字统一用 IEEE 754 双精度浮点数来存储。这个规范决定了它根本没能力精确表示9007199254740993只能就近取一个值。这个 bug 的隐蔽性在于7274837171504734000看起来非常正常没有任何科学计数法、没有任何 null 或 undefined你把它当作一个普通数字传给接口、放进对象、渲染到页面上一切流程都不会报错。唯一的问题就是它已经不是原来那个数字了。等你拿它去数据库里查记录查出来的可能是别人的数据、过期数据甚至查不到。2. 2^53 - 1 这条红线是 JS 的浮点底子划出来的2.1 从 IEEE 754 说起JS 的数字只有一种长相很多初学者会以为 JavaScript 里有整数和小数两种数字类型其实没有。JavaScript 里所有 Number 类型的值不管你是写1、0.5、3.14还是1e100底层都是同一个东西64 位双精度浮点数实现标准就是 IEEE 754。这 64 位的分配方式是这样的1 位符号位决定正负11 位指数位决定这个数在哪个量级52 位尾数位决定这个数的有效精度具体落在哪里。你能记多少位有效数字完全由尾数位决定。IEEE 754 双精度格式实际能提供的有效二进制精度是 53 位因为尾数部分还有一个默认的隐藏位相当于 52 1 53 位二进制有效数字。为什么是 53 位而不是 52 位因为正常的浮点数会做规格化处理最高位总是 1那么这一位就不用存了省出来的空间实际等于多给了一位精度。所以 JS 里所有数字的安全精度上限就是2^53 - 1 9007199254740991。超过这个值的整数Java 里可能还是一个精确的long但到了 JavaScript 里就变成了不可靠数字。2.2 为什么整数也会丢精度浮点数的间隔不是均匀的这是很多人最困惑的一点不是只有小数才会有精度问题吗整数一个一个地数不应该有什么精度损失啊问题就出在JS 的整数并不是一个独立的类型它本质上是指数为 0 时的浮点数。浮点数有一个特性数值越大相邻两个可表示数之间的间隔也越大。因为总的有效位数固定是 53 位当你用指数撑起一个很大的数时尾数能做的事情就只剩下大约表示低位细节已经塞不下了。具体到数字间隔是这个规律数字范围相邻可表示整数的最小间隔0 到 2^53 - 112^53 到 2^54 - 122^54 到 2^55 - 142^55 到 2^56 - 182^56 到 2^57 - 116也就是说跨过2^53之后JS 只能表示偶数再往上只能表示 4 的倍数、8 的倍数。你可以像这样观察console.log(9007199254740991); // 9007199254740991安全 console.log(9007199254740992); // 9007199254740992跨过红线 console.log(9007199254740993); // 9007199254740992被就近取成偶数 console.log(9007199254740995); // 9007199254740996同样被取整了9007199254740993这个奇数在 JS 里根本不存在它只会被解析成9007199254740992。9007199254740995则会被解析成9007199254740996。一个本来存在的数字在 JS 世界里直接消失了这和你用一台只能显示 4 位有效数字的计算器去算123456一样结果只能显示123500或123400个位和十位被抹掉是物理层面的限制。2.3 MAX_SAFE_INTEGER 和 MAX_VALUE别把两者混为一谈JavaScript 内置了一个常量Number.MAX_SAFE_INTEGER值就是9007199254740991。还有另一个常量Number.MAX_VALUE值大约是1.798e308比 2^53 大了不知道多少个数量级。我见过不少同事把这两个搞混以为MAX_VALUE附近还有精度其实大错特错。MAX_VALUE只是能表示的最大绝对值不代表能精确表示这个范围内的所有整数。在大约1e308这个量级相邻可表示数的间隔已经是天文数字了用大白话说就是这个数能表示出来已经耗尽了它在浮点格式里全部的表达能力至于它后面应该跟几个零谁也说不清。所以在实际判断时永远只认两样东西Number.MAX_SAFE_INTEGER9007199254740991Number.MIN_SAFE_INTEGER-9007199254740991超出这两者之间的整数一律默认有精度风险不要用普通 Number 去存、去传、去比较。3. 我踩过的高发场景分布式主键、微秒时间戳、一步运算就爆3.1 分布式系统的标配受害者雪花算法 ID只要是上了微服务、分布式架构的公司订单 ID、用户 ID、消息 ID 大概率都是用雪花算法Snowflake生成的。雪花 ID 通常是 64 位有符号整数符号位占 1 位后还剩 63 位实际生成的值一般在 2^63 以内但2^63和2^53中间差着十万八千里。所以你会遇到这种情况后端把 ID 通过 JSON 返回给前端时如果后端没做特殊处理JSON 序列化会把 Long 类型直接输出成数字字面量。前端拿到后JSON.parse一下这个数字在解析过程中就已经被 JS 截断了。注意这个丢失不是发生在你用id.toFixed()之类的操作时而是在解析的一瞬间就已经发生了。我印象最深的一次是给后台管理系统做滚动分页用的是基于 ID 的游标分页const lastId list[list.length - 1].id; // 假设 lastId 原始值已经是 7274837171504734208 // 上面这一行取到的其实可能是 7274837171504734000下次请求把lastId传回去后端拿这个错误的 ID 去做where id ?结果就是漏掉一部分数据、重复读到另一部分数据。更尴尬的是本地数据量小的时候完全看不出来一上生产数据量大了问题立刻爆发。这种 bug 特别难查因为它的触发条件取决于这个 ID 值是否恰好超过了安全范围而人工肉眼很难判断一个 19 位数字到底有没有超。3.2 时间戳毫秒级别安全微秒和纳秒级别直接崩Date.now()返回的是毫秒时间戳现在大概是 13 位约等于1.7e13还没有到9e15的红线。所以日常处理毫秒级时间戳基本没事。但有两个场景很容易踩线第一个是微秒级时间戳。数据库里的时间精度如果是微秒转成时间戳就是 16 位数字约1.7e16已经超过9e15不少。我做过一个物联网项目设备上报数据带的就是微秒时间后端也算好意想着时间戳你就直接用吧结果前端画图表时某些时间点直接错位、排序乱了。第二个是纳秒级时间戳。Java 的Instant.toString()可以输出纳秒转成数字就是 19 位绝无幸免。遇到这种时间死扛 Number 没有任何意义直接上字符串或者 BigInt。判断方法其实就一句话13 位以下放心用14 位开始留个心眼16 位以上就别再用 Number 存了。3.3 单个数字没超限一参与运算就超限还有一种情况比上面更隐蔽接口返回的每个数字单独看都是安全的但你在前端做了一次运算之后结果瞬间就越界了。比如两个安全范围内的整数相乘const a 999999999; // 9 位 const b 999999999; // 9 位 console.log(a * b); // 999999998000000000a * b的数学结果是999999998000000001但 JS 直接给你变成了999999998000000000。虽然只差 1但在某些对账、统计、幂等计算的场景里差 1 就是事故。更常见的是聚合计算多个订单金额相加、多个库存数量相乘、多个指标汇总。原始数据可能都在安全范围内但累加之后的结果没人保证还在范围内。所以我在很多项目里养成了一个习惯所有涉及大数运算的逻辑不管原始值多小先想清楚这个链路里有没有可能出现超过 2^53 的中间结果而不是只看最终返回值。4. 判断精度是否丢失的三种实操手段4.1 Number.isSafeInteger把守门员放在接口层JavaScript 内置了Number.isSafeInteger()用来判断一个数字是不是安全整数。它不是简单判断是不是整数而是会同时校验这个整数是否在Number.MIN_SAFE_INTEGER和Number.MAX_SAFE_INTEGER之间。Number.isSafeInteger(9007199254740991); // true Number.isSafeInteger(9007199254740992); // false Number.isSafeInteger(1.5); // false Number.isSafeInteger(9007199254740991); // false必须是数字类型注意两个特别容易踩的细节第一这个方法只对 Number 类型生效。你传一个看起来更大的 BigInt 进去它返回false但这不代表这个 BigInt 不安全只是因为类型不对Number.isSafeInteger(9007199254740993n); // false不是 unsafe是类型判定失败第二判断的时机非常重要。我强烈建议把安全判断放在接口接入层在数据进业务代码之前就完成而不是在业务代码里到处加判断。因为数据一旦被JSON.parse之后变成错误的 Number再多的Number.isSafeInteger也只能告诉你它错了无法帮你找回原始值。你可以封装一个小方法在开发环境里对所有接口返回的数值字段做一轮扫描function scanJsonForUnsafeIntegers(obj, path ) { if (typeof obj number !Number.isSafeInteger(obj)) { console.error([精度风险] ${path} ${obj}); } if (obj typeof obj object) { Object.entries(obj).forEach(([key, value]) { scanJsonForUnsafeIntegers(value, ${path}.${key}); }); } return obj; }这套扫描逻辑放进 dev 环境任何接口返回了大整数控制台立刻会提醒你。这样问题在开发阶段就能暴露而不是等用户来找你。4.2 字符串对比法最土但是最权威如果怀疑一个数字已经丢了精度最直接的验证方式是用字符串走一趟。数字的原始形态如果是字符串从字符串转成 Number再转回字符串应该能还原如果还原不了说明第一步转换就已经失真。const raw 7274837171504734208; const num Number(raw); console.log(typeof num); // number console.log(num.toString() raw); // false说明精度在转 Number 时已经丢失这个方法特别适合写测试用例。我给自己维护的工具库加过一组回归用例每次发版跑一遍确保接口契约和序列化逻辑没有悄悄改变const testCases [9007199254740991, 9007199254740992, 7274837171504734208]; testCases.forEach((str) { const back Number(str).toString(); console.log(${str} - ${back} - ${back str ? 安全 : 精度丢失}); });实际运行结果是9007199254740991走了一圈还能回来说明它是安全的9007199254740992还能回来因为它恰好是 2 的幂虽不安全但可精确表示7274837171504734208走不回来了因为 19 位数字已经远远超出尾数表达能力。这个对比法的核心逻辑就是如果我们连一个数字字符串都无法稳定地经过 JS 数字再转回来那我们就不应该在这个数字上做任何依赖数值等于性的判断。4.3 三个看起来没坏、其实已经坏了的陷阱实际排查时有几个特殊的假象特别容易迷惑人。第一个假象是toString()之后看起来挺正常。比如丢失后的数字是7274837171504734000打印出来依然是一串规整的数字没有任何科学计数法、没有NaN、没有Infinity你甚至会觉得它本来就该长这样。正是这种正常感让很多人忽略了它已经错了的事实。第二个假象是JSON.parse没报错就对。JSON.parse({id: 7274837171504734208})完全不会报错它的返回值也是一个看起来正常的对象。JSON 规范本身允许数字是任意精度但 JavaScript 的解析实现没有能力承载这个精度只能默默截断。第三个假象是模板字符串渲染出来没问题。${id}会把一个数字强制转成字符串但如果 id 本身已经丢了精度渲染出来的就是错的那个值。用户看到的界面和数据库里的真实记录不一致但所有人都以为错在别人那一层。如果你排查时遇到上面任何一种情况不用再多想了直接回到第 4.2 节的字符串对比法用最笨的方法验证一遍。5. BigInt 治本现代 JavaScript 的大整数原生方案5.1 BigInt 的基本用法声明、转换、运算一定要在 JS 里处理超大整数的话从 ES2020 开始有一个原生解决方案BigInt。它专门用来表示任意精度的整数不管你的数字有多少位BigInt 都能精确表示。创建方式有两种const a 9007199254740993n; // 字面量结尾加一个 n const b BigInt(7274837171504734208); // 从字符串转换推荐为什么推荐从字符串转换因为像7274837171504734208这种数字字面量如果不加n直接写成普通数字它在解析阶段就已经被转成不精确的 Number 了。所以只要你拿到的原始形态是字符串就永远优先用BigInt(str)。BigInt 的加减乘除和取余运算符都支持但要注意除法是向零取整的const x 10n; const y 3n; console.log(x y); // 13n console.log(x * y); // 30n console.log(x / y); // 3n不是 3.33...小数部分直接截断 console.log(x % y); // 1n也能直接比较大小console.log(9007199254740993n 9007199254740992n); // true console.log(9007199254740993n 9007199254740993n); // true在 BigInt 的世界里9007199254740993就是精确等于它自己的不会再有两个不相等的大整数比较结果为相等这种诡异事件。5.2 BigInt 和 Number 之间的楚河汉界BigInt 和 Number 是两种完全不同的类型不能混用。最典型的报错是这样console.log(1n 1); // TypeError: Cannot mix BigInt and other types你想做运算必须显式把两边转成同一种类型console.log(1n BigInt(1)); // 2n console.log(Number(1n) 1); // 2这里要注意一个方向性问题把 Number 转成 BigInt 是安全的因为 Number 的值在转换前已经不可靠了但至少转换过程不会增加新的错误把 BigInt 转成 Number 则很危险因为大整数转回 Number 时又会经历一遍原来的精度截断。比较运算符也有些讲究console.log(1n 1); // true宽松相等允许比较 console.log(1n 1); // false严格相等要求类型也一致所以在业务代码里尽量统一用一种类型去表达大整数不要今天用 BigInt 明天用 Number否则很容易在和的选择上出事。还有两个 BigInt 的限制必须预先知道第一BigInt 不能直接传给Math对象上的任何方法比如Math.max(1n, 2n)会直接TypeError。第二BigInt 不能直接放进JSON.stringifyJSON.stringify({ id: 9007199254740993n }); // TypeError: Do not know how to serialize a BigInt序列化之前需要先转换成字符串const replacer (key, value) typeof value bigint ? value.toString() : value; JSON.stringify({ id: 9007199254740993n }, replacer); // {id:9007199254740993}5.3 从源头解决让后端把 64 位整数序列化成字符串现在前端很多项目已经可以在接口层引入 BigInt但这里有个极其关键的原则BigInt 必须在数据还没被 JSON.parse 吃掉精度之前就用起来。如果后端返回的 JSON 里是一个裸的数字字面量前端无论怎么折腾 BigInt都已经晚了因为JSON.parse解析的时候数字已经失真你拿到的是一个错误的 Number再用BigInt(错误的Number)也没用。所以治本方案其实是约定接口契约所有 64 位整型字段后端在序列化时一律输出为字符串。以 Java 生态为例Jackson 可以对 Long 字段配置JsonSerialize(using ToStringSerializer.class) private Long orderId;或者全局配置把 Long 和 long 统一序列化为字符串。数据库层面也常见两种做法主键直接用VARCHAR存字符串形式的 ID或者继续用BIGINT存储但保证出接口时转成字符串。核心思想只有一个用什么类型存不重要重要的是 JSON 里不能出现裸的大整数数字。前端拿到字符串后有两种处理路径如果只是展示、去重、作为请求参数回传直接用字符串即可不需要转 BigInt如果要做运算、比较大小、做分页游标就转成 BigInt。const idStr data.orderId; // 7274837171504734208 const idBig BigInt(idStr); // 精确 console.log(idBig.toString() idStr); // true这是我在团队里反复强调的一句话不要让精度问题到前端来解决要让它在接口契约层面就不存在。6. 存量系统兜底字符串契约与第三方解析库6.1 先分清楚什么时候只要字符串什么时候必须上 BigInt有些读者会说我的后端不可能改接口或者说我现在就是在维护一个很老的项目动不了后端的 Java 代码怎么办这种情况下先想清楚你的具体诉求如果只是把 ID 原样渲染到页面、原样传回后端那你只需要保证过程中不丢精度。此时用字符串就够了根本不需要 BigInt。如果你还需要对这个大整数做比较大小、排序、加减运算比如分页游标的大小判断、多个大数求和那么字符串方案就撑不住了必须转成 BigInt 或使用第三方高精度库。这里有一个经验能不用 BigInt 的时候就尽量不用。不是说 BigInt 不好而是 BigInt 与 Number / JSON / 部分第三方库的互通性限制比较多引入它等于给项目增加了一类需要小心的类型边界。只有在确实需要运算的时候再转。6.2 三个十进制高精度库怎么选big.js、decimal.js、bignumber.jsBigInt 只能处理整数。如果你要处理的是金额、百分比、汇率这种需要小数的场景BigInt 就不够用了。这时候我一般在这三个库里面选big.js、decimal.js、bignumber.js。它们的底层都是十进制运算不会出现0.1 0.2 ! 0.3这种二进制浮点的经典问题。特性big.jsdecimal.jsbignumber.js包体积最小中等较大十进制精度支持支持可配置精度支持可配置精度数学函数基础四则运算较完整最完整适合场景简单金额计算金融、财务计算复杂统计、需要幂运算我的选择习惯是写个小工具函数处理个金额加减用 big.js就够了如果涉及财务对账、复利计算这类需要可控精度的场景用 decimal.js 或 bignumber.js如果是整个项目有很多种高精度运算需求再考虑引入 math.js 这种全家桶。不要一上来就追求功能最全的库包的体积和应用复杂度都要权衡。如果你在使用 axios 这类 HTTP 客户端并且后端暂时只能返回裸数字你可以在transformResponse里用第三方解析库把大整数保留下来const JSONbig require(json-bigint)({ useNativeBigInt: true }); axios.get(/api/order, { transformResponse: [(data) { return JSONbig.parse(data); }] }).then((res) { console.log(typeof res.data.orderId); // bigint console.log(res.data.orderId.toString()); // 精确还原 });这样前端拿到的不再是一个早已失真的 Number而是精确的 BigInt。注意json-bigint默认会把 JSON 里的整数都转成 BigInt你在使用时需要确认团队成员都清楚这个行为否则某些原本安全的数字字段突然变成 bigint可能会引发类型判断上的连锁反应。6.3 JSON.parse 的 reviver 参数救不了已经丢的精度关于精度兜底我见过非常多的人走弯路最常见的一个思路是用JSON.parse的第二个参数 reviver 来处理大数字。const data JSON.parse(jsonStr, (key, value) { if (typeof value number !Number.isSafeInteger(value)) { return BigInt(value); // 这是错误的 } return value; });这个方案看起来很美但实际是无效的。因为JSON.parse的 reviver 是在整个解析完成之后才逐个调用也就是说大数字在解析阶段就已经被转成了不精确的 Number等 reviver 执行的时候value早就不是原始大整数了。你这时候再BigInt(value)转换的是错误值。正确做法只有两种要么让后端在 JSON 里输出字符串要么用自定义解析器比如上面提到的json-bigint在解析阶段就拦截数字文本。除此之外没有第三条路。7. 我放在团队规范里的四条铁律7.1 铁律一所有 64 位整型字段API 契约里一律写 string这条没有商量余地。不管是订单 ID、用户 ID、消息 ID还是任何可能超过2^53 - 1的整型字段接口文档和代码实现都统一按字符串输出、按字符串接收。有人担心字符串做索引、做比较会慢实际上前端只是透传真正的索引和比较都在数据库层面完成字符串类型在数据库里一样能做索引。7.2 铁律二涉及大数运算先问能不能换成 BigInt 或高精度库业务代码里一旦出现乘法、加法、除法先看一眼操作数的量级。如果两个数都是九位数相乘的结果可能就逼近红线了。我会习惯性地问自己一句这个结果的预期最大值是多少如果预期值可能超过9e15就直接用 BigInt 写不要等线上炸了再补。7.3 铁律三接口层加精度扫描让问题暴露在开发时就是第 4.1 节那个scanJsonForUnsafeIntegers在 dev 环境和测试环境全链路跑一遍。只要接口返回了不安全的 Number立刻打印警告。这样即使某个后端某天忘了把大整数转字符串前端开发也能在第一时间收到提示而不是让 bug 悄悄溜到生产环境。7.4 铁律四测试用例永远保留一组大整数样例我自己的工具库和组件库现在固定会放一组大整数回归用例9007199254740991安全整数的边界应当能精确处理9007199254740992不安全但可精确表示的偶数需要明确区分7274837171504734208典型的 19 位雪花 ID必须能精确往返。每次发版跑一遍任何一次序列化逻辑改动导致精度回归都能立刻被抓出来。这套用例看起来简单却比任何 code review 都有效。最后再分享一个调试小技巧如果你在控制台看到一个特别大的数字不确定它是不是错了先String(value)然后和数据库里的原始字符串对比如果对不上基本可以断定精度已经丢了。这个习惯帮我省下了很多排查时间也希望对你有点用。