★ FEATURED ARTICLE 先说一个我印象很深的线上事故。业务方反馈所有订单详情页打开都是空白我打开Network面板一看接口返回的订单ID是1770123456789123456可前端控制台打印出来的却是1770123456789123400——尾部三位直接变成了0。那一刻我立刻意识到这不是后端数据问题也不是某个同事写错代码而是JavaScript的Number精度边界在无声无息地吃掉我们的ID。这种问题在早期Web开发里几乎不会被前端感知因为数据库自增主键最多到十一位但自从雪花ID这类分布式ID方案普及之后19位甚至20位的ID成了标配前端id精度不足就从一个冷门知识点变成了每个中大型系统都会踩的坑。这篇文章就围绕“前端id精度不足”这件事把成因、踩坑场景、完整修复方案和团队防御手段一次说清楚。不管你是刚入行的前端还是正在维护高并发中后台的老手这篇文章都能帮你少走弯路。1. 先搞清楚前端ID为什么说丢就丢1.1 Number的精度边界藏在二进制里JavaScript里的Number完全遵循IEEE 754双精度浮点数标准本质上是用64位二进制来存储一个数字1位符号位、11位指数位、52位尾数位。真正决定“能精确表示多少位整数”的是尾数位52位二进制有效位换算成十进制大约是15到16位有效数字。这里有个官方给的硬性常量console.log(Number.MAX_SAFE_INTEGER); // 9007199254740991这个值就是2的53次方减1约9.007e15。所有不超过它的整数在JavaScript里都能被精确表示一旦超过它连续整数之间就开始出现“断层”有些整数在Number的世界里根本不存在。最经典的验证代码所有人都应该亲手跑一次console.log(9007199254740992 9007199254740993); // true你没看错两个不同的整数在JavaScript里居然相等。因为2的53次方加1这个数在双精度浮点数的表达集合里不存在只能回退到最近的偶数。我用一个生活化类比来解释想象一把算盘只有52颗珠子商家要找给你一笔超过算盘容量的零钱多出来的分币只能按“四舍五入”规则扔掉最后你拿到手的钱和实际金额对不上。前端丢精度就是“珠子不够用”了。1.2 雪花ID这种19位数字是最典型的受害者聊到业务场景最惨的就是雪花ID。雪花算法生成的分布式ID是64位长整型通常落地成19位十进制数字比如1770123456789123456。而Number.MAX_SAFE_INTEGER是9.007e15级别19位数是1e18级别直接超了一个数量级。也就是说只要后端用雪花ID、Leaf、UidGenerator这类方案生成主键大多数ID都会超出安全范围必然会触发精度丢失。丢失的具体表现很有规律尾数位不够表达时会按二进制舍入规则处理反映到十进制上就是末尾几位变成0。比如1770123456789123456在浏览器里的真实输出是1770123456789123400。这不是某次请求偶然出错而是每一次JSON.parse之后都会发生的确定性行为。1.3 一个简单方法快速判断你的ID有没有丢精度实际排查的时候不用翻源码打开浏览器Network面板和Console对比就能判断。看接口原始返回的JSON里id是数字还是字符串再看前端打印出来的值是否一致const id 1770123456789123456; console.log(id); // 1770123456789123400 console.log(Number.isSafeInteger(id)); // false这里的Number.isSafeInteger返回false说明这个值已经超出了安全整数范围。但要注意一个关键细节这个判断只能告诉你“当前这个值不安全”如果你发现的时候它已经被解析过原始值就永远找不回来了。所以实战中我更倾向于肉眼观察ID末尾是否连续出现0这是丢精度最直接的信号。2. 哪些场景最容易踩中“精度不足”的大坑2.1 列表展示正常一进详情或删除就报错这是我从运维同事那里听到最多的吐槽。列表页明明数据都在点击详情却提示记录不存在或者点了删除毫无反应。排查到最后问题往往出在列表接口和详情接口返回的ID形态不一致。有些后端在列表里返回了字符串ID前端在跳转详情时却自作主张用Number(id)转了一次就这一下精度就丢了。更隐蔽的是隐藏域或缓存里的ID界面上看不到问题但请求发出去时已经错得离谱。2.2 表格多选、展开、排序行为错乱如果你用的是Ant Design Table或者Element Plus的Table给rowKey传了record.id而id已经丢精度变成相同的值那么恭喜你你会看到一系列诡异现象选中一行结果三行被选中展开某一行结果另一行展开了排序结果完全对不上。原因很简单框架内部拿rowKey当作唯一键来对比行多行ID相同就会被当成同一行。React里还会直接报Encountered two children with the same key警告。这类问题的隐蔽性极强因为页面不报红色错误只是行为“不太对”非常容易误判成业务逻辑Bug。2.3 路由参数、localStorage按ID操作时的二次丢失我一直觉得前端ID精度问题最坑的地方在于它会在链路里反复丢失。路由跳转时把id放在query里字符串传过去本来没事但接收方如果习惯性parseInt一下又丢一次。还有很多人喜欢把列表数据缓存到localStorage存的时候走一遍JSON.stringify取的时候走一遍JSON.parse在这两轮过程中超过安全范围的数字就会被悄悄改写成近似值。我之前接手过一个根据id删除localStorage数据的模块删除逻辑怎么测都失效最后发现缓存里的id早就从2012345678901234567变成了2012345678901234500拿标准值去删当然永远删不掉。2.4 微前端和跨应用通信中的隐形传播微前端架构下主应用和子应用之间经常通过postMessage或者全局事件总线传递业务数据。如果payload里的ID是Number类型主应用发一遍、子应用收一遍中间至少经历一次序列化精度大概率保不住。数字孪生、大屏项目里设备ID和工位ID动辄19位跨系统对接时这个问题会被放大。注意子应用自己加的请求拦截器只能管自己的接口主应用携带的ID如果已经错了后面的应用全在拿错误ID做业务。业务场景典型ID位数风险等级电商订单号/快递单号18~19位高OA审批流程实例ID18~19位高物联网设备ID/数字孪生节点ID19位高SaaS租户ID/用户ID部分平台18~19位中CRM/数据同步记录ID18~19位中3. 解决方案体系从传输层到展示层的完整修复3.1 最优解让ID以字符串形态进入前端精度丢失发生的那一刻就是JSON.parse把数字塞进Number容器的时候。所以最根本的思路是在解析JSON之前就介入把超安全范围的整数转成字符串。这比在业务层补救安全一万倍因为数据一旦进入Number就像牛奶倒进咖啡再也回不去了。实际操作中优先推动后端把Long类型的ID序列化为字符串。Java后端在Spring Boot里可以全局配置Jackson把所有Long字段输出为字符串Configuration public class JacksonConfig { Bean public Jackson2ObjectMapperBuilderCustomizer longToStringCustomizer() { return builder - builder .serializerByType(Long.class, ToStringSerializer.instance) .serializerByType(Long.TYPE, ToStringSerializer.instance); } }配置之后前端拿到的JSON里id就是1770123456789123456这样的字符串。字符串无论多长都不会有精度问题前端拿到后原样传递、原样展示彻底绝隐患。如果你用的是fastjson也有对应的SerializerFeature.WriteNonStringValueAsString特性效果一样。所有方案里这是我认为的治本手段。3.2 用json-bigint接管axios的响应解析如果后端暂时改不了前端必须自己救自己。业界最成熟的工具是json-bigint它在JSON.parse之前对文本进行特殊处理把超过安全范围的整数自动转成字符串或BigInt。先安装依赖npm install json-bigint关键点在于接入位置必须足够早。很多同学踩过这个坑在axios响应拦截器里parse已经晚了因为response.data早就被axios内置逻辑通过JSON.parse处理过了。真正要覆盖的是transformResponse这个配置会替换掉axios默认的解析函数import axios from axios; import JSONbig from json-bigint; const jsonBig JSONbig({ storeAsString: true }); const request axios.create({ baseURL: /api, transformResponse: [ (data) { if (typeof data string data) { try { return jsonBig.parse(data); } catch (error) { return data; } } return data; } ] });这里storeAsString: true的语义是只有超过安全范围的整数才转成字符串普通数字保持原样。所以完全不用担心后端返回的金额、数量、年龄等正常数字被误伤。这个方案几乎可以无痛接入所有基于axios的项目也是我目前在团队里强制推行的方案。3.3 BigInt方案能用但要清楚边界ES2020之后JavaScript有了原生BigInt可以用来精确表示任意大的整数。它的确能解决问题但使用限制非常多不能当银弹直接铺开。你可以这样使用const bigId BigInt(1770123456789123456); console.log(bigId.toString()); // 1770123456789123456但要注意三个致命细节。第一BigInt不能和普通Number直接混用运算1n 1会直接抛TypeError第二JSON.stringify({ id: 1770123456789123456n })会直接报Do not know how to serialize a BigInt因为JSON规范里根本没有BigInt类型第三如果数据已经在JSON.parse阶段丢了精度再BigInt(id)也没用因为原始值已经没了。所以我的建议是BigInt适合在后端返回字符串或BigInt形态的受控场景里使用不适合用来“事后补救”。如果非要全局给BigInt加toJSON方法那就等于在所有地方把它序列化成字符串本质上又回到了字符串方案那不如一开始就让后端输出字符串。3.4 前端兜底统一的安全ID处理函数不管接口返回的是数字、字符串还是BigInt业务代码里总得有个统一的兜底函数把ID规范成字符串。我项目里一直维护一个safeId函数export function safeId(id) { if (id null || id undefined) return id; if (typeof id bigint) return id.toString(); if (typeof id string) return id; return id.toString(); }所有涉及ID赋值、ID比较、ID传参的地方一律先走safeId。这个函数看起来简单价值在于给了全团队一个唯一的出口代码审查时只要看到Number(id)、parseInt(id)、id这样的写法直接打回去要求改用safeId。另外拿ID做相等判断时千万不要让字符串和数字比较因为1770123456789123456 1770123456789123456一定是false。3.5 前端传参时如何避免第二次丢精度还有一个容易忽略的点前端把ID传给后端时也要保持字符串形态。有人在前端已经拿到字符串ID了结果提交表单时为了对齐后端类型又悄悄转成数字前功尽弃。查询参数里保持字符串没问题路径参数里保持字符串也没问题请求体里同样保持字符串。如果后端接口文档写的入参是Long类型但你前端又没有能力修改后端那就要评估这个后端接口是不是已经被同类型问题困扰推动后端改成String入参才是正解。4. 实战问题排查与修复记录4.1 一次线上“ID尾号变00”的完整排查实录这个案例来自我维护的某个数据同步平台。运营反馈Excel导出的关联记录在导入后全部无法绑定到原数据。我按三步排查。第一步看网络层。打开Network发现同步接口返回的sourceId确实是1770123456789123456没有输错。第二步看业务层。Console里打印record.sourceId结果变成了1770123456789123400末尾三位被改写了。第三步定位责任端。我确认当前前端代码没有做任何转换但axios默认的JSON.parse在响应进入拦截器前已经执行精度就在那里丢的。修复动作就是在transformResponse里接入json-bigint代码见3.2节发布后重新测试sourceId正确显示为字符串导入绑定成功。后续我又看了仓库历史发现这个平台的前端从创建第一天起就有精度问题只是数据量没到阈值始终没有暴露直到出现19位ID才集中爆发。4.2 问题速查表现象、原因、解法对照我把日常工作中遇到的高频问题和对应解法整理成了速查表社区里讨论的很多case都能对上号现象根本原因推荐解法接口返回正确前端打印ID末尾为0JSON.parse导致数字超安全范围被舍入请求层用json-bigint或后端Long转String列表正常详情/删除/编辑失败跳转时对字符串ID执行了Number()转换删除所有对ID的Number()、parseInt()调用Table多行选中或展开错乱rowKey用了已丢精度的数字ID多行ID相同rowKey改用后端返回的字符串ID或safeId(id)localStorage缓存按ID删除失败缓存存取过程中JSON.parse改写了ID存储时对ID统一safeId转字符串React报告“two children with the same key”多个子组件的key是相同数字key统一用字符串形式JSON.stringify(BigInt)报错JSON规范不支持BigInt类型传输格式统一用字符串不用BigInt做载体微前端消息传递后ID对不上postMessage/payload里ID被序列化多次主应用与子应用统一接入相同的请求层处理4.3 2026年前端面试题视角这个问题可以这样答说来有意思现在前端面试题里“ID精度不足”的出现频率越来越高基本成了分布式场景下的必考点。面试官问你“前端如何避免Long类型精度丢失”时可以按这套思路回答。先讲原理JavaScript的Number是IEEE 754双精度浮点数安全整数范围是2的53次方减1约9.007e15超过这个范围的整数无法精确存储。分布式ID如雪花ID通常是19位必然超出安全范围所以在JSON.parse时就会被四舍五入表现为ID末尾变0。再讲解决方案首选是后端把Long类型序列化为字符串从源头杜绝问题如果后端改不了前端在axios的transformResponse阶段用json-bigint把超范围整数转成字符串进阶方案是使用BigInt但要注意它不能直接JSON.stringify也不能与Number混用运算。最后补充一个体现深度的点不要在业务层用Number(id)、parseInt(id)补救因为数据在JSON.parse时就丢了后面做什么都救不回来。这个回答框架把原理、方案、边界都说清了面试官想追问都难。4.4 避坑清单我踩过的五次坑和总结这里写几个实打实的教训都是文档里不太会写的。第一不要在任何一个前端文件里写Number(id)、parseInt(id)、id、~~id。我在代码审查里每次看到这种写法都会追问一句“这个ID确定不超过安全范围吗”十次里有八次对方答不上来。第二axios的响应拦截器里再处理已经晚了。很多博客推荐在拦截器里挂JSONbig.parse但经过我实测response.data在拦截器阶段已经是对象精度早丢了。必须用transformResponse覆盖默认解析或者更进一步在请求适配器层面处理原始文本。第三如果你的工程用了TypeScript给ID字段定义类型时尽量用string | number而不是number。团队规范里标识“所有ID字段按字符串处理”能减少一大部分误用。第四微前端场景下主应用和子应用都要各自配置json-bigint。只配子应用的话主应用传过去的payload里ID可能已经变成错误数字了子应用拿到手再解析也无济于事。第五如果你的构建工具或目标浏览器版本较老要确认一下BigInt语法能正常编译tsconfig的target建议不低于es2020。这个坑我曾经在低版本Chrome内核的嵌入式设备上踩过页面直接白屏。5. 长期防御在团队规范层面堵住精度问题5.1 前后端契约里明确ID类型“前端id精度不足”本质上不是一个纯前端问题它是前后端数据契约缺失导致的。最有效的长期方案是API文档里把所有ID字段标注为string类型并在Swagger/OpenAPI的schema里把type写成string而不是integer。联调阶段也约定超过15位的数字ID后端不允许返回Number类型。这个约定越早定后面的返工越少。5.2 封装统一请求层全局拦截转义我在团队里一直强调“请求层收口”的价值。所有业务请求必须走同一个封装好的axios实例json-bigint配置只写一次全项目生效。如果项目里有些老模块绕过封装直接fetch需要花时间改造因为只要有一个口子没有拦截线上就可能冒出一个隐蔽的ID精度Bug。封装的好处还在于后续后端如果统一改成字符串ID前端改动面极小只需要微调解析配置。5.3 代码审查与自测清单最后给一份可以直接抄走的Checklist我在GitLab的MR模板里就是这么放的检查接口返回的ID字段在Network原始JSON里是否为字符串检查代码中是否存在Number(id)、parseInt(id)、id、~~id写法检查Table的rowKey是否使用safeId(id)或后端字符串ID检查localStorage和路由跳转场景下ID是否经历了JSON.parse检查微前端通信的payload是否经过统一请求层抽查一条19位ID在全链路列表到详情到删除是否全程保真。这套清单实施之后我们线上由ID精度引发的事故从每周好几起降到了半年一起。说到底前端ID精度不足这个问题技术上并不难解决难的是让整个团队都意识到“数字ID在JavaScript里不可信”并且把防御动作做在数据入口而不是业务出口。最后分享一个我自己的习惯每次接到新项目或者接手老系统第一件事就是打开Network面板把接口返回的每一个ID字段都肉眼过一遍看它们到底是数字还是字符串。这个习惯帮我至少避免了两次线上事故。如果你也想彻底告别“前端id精度不足”这个幺蛾子记住三句话能传字符串就不传数字能在请求层解析就别等到业务层补救能在后端修就别让前端硬抗。
阅读完成 · 觉得有帮助？
