企业官网建设流程全解析

number类型超出16位这个坑，我敢说绝大多数做过后台管理系统或者电商项目的同学都踩过。最典型的场景就是：后端辛辛苦苦生成一个雪花ID，或者数据库自增主键到了16位，前端页面上列表显示还好好的，一点"编辑"按钮，跳详情页，ID错了，数据查不出来。更隐蔽的是，你在浏览器控制台打印这个ID，它已经变成了一个以...00结尾的"假数"。

我之前在排查一个订单号展示问题的时候，就是被这个坑绊了一跤。明明后端返回的订单号是对的，前端展示出来却总是差几位，更诡异的是，有时候对，有时候不对。最后定位到是number类型精度丢失，那会儿才真正意识到，16位这个数字就是JavaScript数字类型的一条生死线。

这篇文章我不打算只泛泛地说"用字符串"或者"用BigInt"，我想把前端、后端各自的处理方案、背后的原理、以及最容易让人忽略的边界情况都掰开揉碎讲一遍。无论你是刚入门的前端，还是负责接口设计的后端，这篇应该都能给你一些参考。

1. JavaScript的number类型为什么"数不清"16位以上的整数

先说结论：JavaScript的number类型不是纯粹的整数类型，它采用的是IEEE 754标准的双精度浮点数（Double Precision）格式。也就是说，它底层是用二进制科学计数法来存所有数字的，包括整数。

1.1 双精度浮点数的存储结构决定了精度上限

一个双精度浮点数占用64位，由三部分组成：1位符号位、11位指数位、52位尾数位。这意味着52位尾数决定了它能精确表示的整数范围。

简单算一下：当指数部分足够大时，52位尾数能精确区分的最大连续整数是2^53 - 1，也就是9007199254740991。这是一个16位的数字。而2^53是9007199254740992，其实也能表示，因为它是2的幂，但2^53 + 1就出问题了，它会被舍入成2^53。

提示：很多文章说"最大安全整数是2^53 - 1"，这个说法不完全准确。准确地说，从0到2^53，所有整数都是可以精确表示的，但2^53之后的奇数就开始无法精确表示了。所以把9007199254740991（16位）当作安全上限来用，是最稳妥的。

1.2 16位是分界线，但并非所有16位数字都安全

这里有个很容易误导人的地方。很多人以为"只要是16位以内的整数就绝对安全"，其实不对。从0到9007199254740991，这个区间内的所有整数都是安全的。但超过这个值后，即使是16位，也可能出错。

比如9007199254740993，这是一个16位数字，但它超出了安全范围，实际存进去会变成9007199254740992。这个数字看着挺正常，但它已经"变味"了。

所以"超出16位"这个问题，本质上不只是位数问题，而是数值大小是否超过2^53 - 1的问题。只不过大多数场景里，超过16位的整数基本都会触发这个问题，大家就习惯用"16位"来称呼了。

1.3 什么场景最容易触发

触发这个问题的场景非常固定，基本集中在以下几类：

• 数据库自增主键：单表数据量大了之后，主键轻松突破16位，尤其是分库分表后用了雪花算法之类的ID生成器，出来的ID动辄19位。
• 第三方接口返回的大整数：比如微信支付、支付宝回调里的交易流水号，很多都超过16位。
• 前端自己生成的临时ID：比如用Date.now()加随机数拼一个唯一标识，某些极端情况下也会超。
• 数值计算中的中间结果：比如两个接近2^53的数相加，结果就超出了安全范围。

理解了这个边界，我们才可以谈后面具体怎么处理。

2. 前端侧的处理：从"被动踩坑"到"主动防御"

前端作为数据显示的最后一环，经常要直面这个精度问题。但很多同学发现，自己在代码层面已经做了处理，怎么还是会丢精度？因为精度丢失发生在数据进入JavaScript运行时的那一刻，等到你写业务代码去判断、去格式化时，值已经错了。

2.1 模式一：字符串透传，最笨但最有效

前端最容易忽略的其实是请求响应阶段。如果你用的是axios，没做任何特殊处理，那么后端返回的JSON字符串会先被JSON.parse转换一次，这个过程中数字就已经被解析成number类型了。

最直观的解决方案是：后端返回时，把所有可能超16位的数字字段转成字符串。前端拿到字符串，不主动做Number()转换，直接展示或者传给下一个接口。

// 后端返回的JSON { "orderId": "9007199254740993", // 字符串 "status": 1 }

前端这里有一个容易被骂的点：很多人拿到字符串后，觉得它是字符串格式，会在展示时顺手Number(orderId)一下，或者在下单接口时，因为后端参数要求是数字，又转了回去，结果精度又丢了。

建议在前端维护一个约定：凡是字段名以Id、No、Sn、Code结尾的，一律不转数字，即使后端某天误返回了数字类型，也不要在前端做转换。

2.2 模式二：JSON.parse 的 reviver 函数拦截

靠后端自觉转字符串并不是万无一失的。有时候你对接的是老项目，接口已经返回了数字类型，没法改。这时候前端可以在解析JSON时做一次"抢救"。

JSON.parse支持传入第二个参数reviver，在属性值被真正返回给调用方之前，你有机会拦截它：

const jsonString = '{"orderId": 9007199254740993, "count": 2}'; const result = JSON.parse(jsonString, (key, value) => { if (typeof value === 'number' && !Number.isSafeInteger(value)) { // 超出安全整数范围，转成字符串或者BigInt return value.toString(); } return value; }); console.log(result.orderId); // "9007199254740993"

这个方案有个坑，就是你只能在字符串尚未被转换成数字之前拦截。也就是说，reviver接到的value其实已经是9007199254740992了，你再去value.toString()，得到的也是错误的字符串。因为解析过程是先转成数字，再交给reviver。

正确做法是：在解析之前，用正则对原始字符串做预处理，给那些超长数字加上引号，然后再JSON.parse。

function parseJsonWithBigInt(jsonString) { // 给超过16位的纯数字加上引号 const sanitized = jsonString.replace( /([:]?\s*)(\d{17,})(\s*[,}\]])/g, '$1"$2"$3' ); return JSON.parse(sanitized, (key, value) => { if (typeof value === 'string' && /^\d{17,}$/.test(value)) { return BigInt(value); } return value; }); }

2.3 模式三：升级解析库，json-bigint

如果项目里超长整数出现频率很高，或者你不想自己维护那套正则，可以考虑直接用json-bigint这个库替换原生的JSON.parse。

import JSONBig from 'json-bigint'; const jsonString = '{"orderId": 9007199254740993}'; const result = JSONBig.parse(jsonString); console.log(result.orderId.toString()); // "9007199254740993"

这个库的原理其实也简单：它自己实现了一个JSON解析器，遇到数字时会先判断是否超过Number.MAX_SAFE_INTEGER，如果超过就用BigNumber类型保存，而不是直接转成number。

但要注意，用了它之后，你拿到的值不再是number，而是一个对象，操作上要格外小心，比如result.orderId + 1这种写法会出错。建议只在字段确实可能超长的接口里用，不要让全局的axios实例直接引入，否则对已有代码的侵入性太强。

2.4 模式四：彻底拥抱BigInt原生类型

如果你不需要考虑老浏览器，并且项目是纯前端处理大整数，那完全可以考虑用BigInt。

BigInt是ES2020引入的原生类型，它可以精确表示任意大的整数。但它有几个限制：

• 不能和number类型直接混合运算：1n + 1会直接报错，必须显式转换。
• 不能传给JSON.stringify：直接序列化会抛异常。
• 不支持Math对象的方法。

所以BigInt更适合做内部计算，不适合作为接口传输层的数据类型。

const bigOrderId = BigInt("9007199254740993"); const nextId = bigOrderId + 1n; // 如果需要传给后端，转成字符串 const payload = JSON.stringify({ orderId: nextId.toString() });

3. 后端侧的处理：源头不解决，前端再怎么折腾都白搭

前端所有的"抢救措施"，本质上都是在给后端的"偷懒"擦屁股。如果后端在序列化阶段就把超长整数输出成数字类型，前端的正则、reviver、json-bigint全都只能拿到一个已经丢精度的值。

所以这个问题的根治点，一定在后端。

3.1 Java后端最常见的坑：Long类型直接序列化

以Java的Spring Boot项目为例，实体类里很常见的写法：

public class Order { private Long orderId; private Integer status; }

默认情况下，Jackson序列化时会把Long类型直接输出为JSON数字。如果这个orderId是雪花算法生成的19位数字，前端拿到手的那一刻就已经废了。

前端可能看到的是：

{ "orderId": 9007199254740992, "status": 1 }

但数据库里的真实值是9007199254740993，已经差了1。这种错误特别隐蔽，因为只有部分值会受影响，还有一部分恰好在安全范围内的值又是对的。

3.2 方案一：局部注解，只针对关键字段

最简单的办法是在实体类字段上加注解，让Jackson在序列化时把这个字段当字符串输出：

public class Order { @JsonSerialize(using = ToStringSerializer.class) private Long orderId; }

这样输出的JSON就是：

{ "orderId": "9007199254740993", "status": 1 }

ToStringSerializer是Jackson自带的序列化器，作用是调toString()，把Long变成字符串。

这个方案的好处是精准、影响面小，适合只有个别字段需要处理的场景。缺点是如果字段很多，你得一个个加，很容易漏。

3.3 方案二：全局配置，一劳永逸

如果你项目里大量使用Long类型作为主键或业务编号，建议直接全局配置。在Spring Boot中，可以通过自定义Jackson2ObjectMapperBuilderCustomizer来实现：

@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder -> { // 将 Long 和 long 类型统一序列化为字符串 builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; } }

配置完成之后，所有接口返回的Long类型字段都会自动变成字符串。

但这里要特别注意一个问题：不能无脑把所有Long都转成字符串。因为有些字段在业务语义上并不是ID，比如统计数量、时间戳（毫秒值），转成字符串后前端的计算逻辑就要跟着改。虽然大部分情况问题不大，但要评估清楚。

一个折中的方案是，只把Long类型里符合特定命名规则的字段转字符串，比如字段名以Id、No、Sn结尾的：

@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder -> { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; } }

如果你坚持全局转字符串，建议在后端文档里明确标注每个字段的类型，防止前端误把ID字符串当数字去运算。

3.4 方案三：数据库层面的设计配合

从数据库角度讲，如果主键是自增的bigint，在单表数据量几百万的情况下，很少会撞到16位。但一旦分库分表，自增ID就不好使了，主流的方案是采用雪花算法（Snowflake）生成的分布式ID，这种ID是19位的bigint，必然超出安全范围。

我的建议是：

• 业务主键：如果能用字符串类型（varchar）存主键，优先用字符串。比如订单号，用yyyyMMddHHmmss加随机数生成，长度可控，还是字符串，天然免疫精度问题。
• 代理主键（数据库内部分表用的自增ID）：只在内网、服务间传递，不出现在对外接口里。如果一定要出现在接口里，必须转字符串。
• 唯一业务编号：比如支付流水号、对账单号，直接用字符串类型存储，不要在中间环节转成Long。

数据库设计上的一个小改动，能省掉后面无数个bug。

3.5 其他后端语言的情况

Java是重灾区，但其他后端语言也有类似问题，只是表现不同：

• Python：Python 3的int是变长的，理论上可以无限大，所以json.dumps时不会丢精度。但前端JavaScript拿到大整数时，仍然会在JSON.parse阶段丢精度。所以Python后端也要注意，如果在接口层返回大整数，前端同样会出问题，该转字符串还是要转。
• Go：Go的int64在JSON序列化时默认是数字，同样会触发前端的精度问题。需要在MarshalJSON里做字符串转换。
• C# / .NET：和Java类似，默认long序列化为数字，需要配置JsonSerializerOptions或使用[JsonConverter(typeof(ToStringJsonConverter))]。

4. 前后端联调中的"链路一体制"：16位问题的完整处理流程

前文分别讲了前端和后端各自的方案，但实际项目里，跨端问题最难的从来不是某一端的解决，而是链路里所有环节的协同。16位数值精度问题正是如此：就算后端做了全局转字符串，如果前端不知道，或者中间网关、日志系统多了一道转换，照样出问题。

我画了一条清晰的链路，按顺序排查基本都能定位到问题：

数据库 -> 后端实体类 -> ORM映射 -> 后端序列化 -> 网关/代理 -> 前端请求库 -> 前端业务代码

每一环都有可能成为丢精度的元凶。

4.1 从数据库到后端实体的映射阶段

这一阶段最容易踩的坑是：数据库字段是varchar，后端实体类却是Long。

很多老项目在设计表结构时，订单号、流水号用的是varchar(32)，但后端实体类图省事，写成了Long。这样ORM（比如MyBatis-Plus）在查询时，会自动尝试把字符串转成Long，虽然大多数时候能转成功，但一旦字符串长度超过Long的范围，或者字符串里带了非数字字符，就会抛转换异常。

即使没抛异常，这个阶段也可能引入精度问题。举个例子：数据库里存的是"9007199254740993"，转成Long后，在Java里其实还是精确的（Java的Long是64位有符号整数，最大能到9223372036854775807），但到了JSON序列化，又被输出成数字，前端JSON.parse时丢精度。

所以这里的原则是：数据库是什么类型，后端实体类就用什么类型。数据库是varchar，实体类就用String，而不是Long。

4.2 从后端到前端的序列化阶段

这一阶段就是后端的序列化配置问题。不管用Jackson还是Fastjson，都要做统一处理。

Fastjson的全局配置方式略有不同：

@Configuration public class FastjsonConfig { @Bean public HttpMessageConverters fastJsonHttpMessageConverter() { FastJsonConfig config = new FastJsonConfig(); config.setSerializerFeatures(SerializerFeature.BrowserCompatible); // 或者使用 ValueFilter config.setSerializeFilters((object, name, value) -> { if (value instanceof Long) { return value.toString(); } return value; }); // ... } }

如果你用的是Spring Boot默认的Jackson，前文那种Jackson2ObjectMapperBuilderCustomizer的写法就够了。但有个细节容易忽略：如果项目里某些接口用了@ResponseBody返回String类型，序列化时会原样返回，不会经过Jackson的转换。这种情况不会丢精度，但前端的类型就变成了字符串，如果调用方期望的是数字，也会出问题。

4.3 网关与日志系统的"好意"反而坏事

这一阶段是很多人完全想不到的。我遇到过一种情况：后端明明已经返回了字符串类型，但前端拿到的却还是数字。查了很久才发现，是网关层对JSON响应做了一次"美化"，把看起来像数字的字符串自动转成了数字类型。

比如Kong、Spring Cloud Gateway等网关中间件，如果配置了JSON body重写，或者在做日志记录时对响应体做了JSON.parse后再JSON.stringify，就会在不知不觉中把"9007199254740993"变成9007199254740992。

排查方法很简单：绕开网关，直连后端服务，对比两次响应的差异。如果直连返回的是字符串，走网关就变成数字，问题一定出在网关层。

日志系统同理。很多团队会在网关或拦截器里统一打印请求响应日志，日志系统如果也做了JSON格式化，同样可能影响原始响应体。虽然日志本身不一定会影响返回结果，但如果日志组件在格式化时修改了响应流，就可能导致客户端拿到被"优化"过的数据。

4.4 前端从请求库到业务代码的传递

当后端确认返回的是字符串后，前端只要不主动转数字，基本就没事了。

但有一种情况比较麻烦：前端拿到的ID字符串，在传给下一个接口时，又会通过qs或URLSearchParams进行参数序列化。有些库会自作聪明地把看起来像数字的字符串转成数字。比如：

import qs from 'qs'; const params = { orderId: '9007199254740993' }; console.log(qs.stringify(params)); // orderId=9007199254740993（正常）

大概率不会出问题，但如果你用了某些第三方库，比如axios的params序列化器，或者自己手写了参数拼接逻辑，就要留意是否做了Number()转换。

我的建议是，前端在请求拦截器里统一处理参数，凡是ID类的字段，一律String(value)强制转字符串：

const stringifyIdFields = (data) => { const result = {}; Object.keys(data).forEach((key) => { if (/Id|No|Sn|Code$/i.test(key) && data[key] !== null && data[key] !== undefined) { result[key] = String(data[key]); } else { result[key] = data[key]; } }); return result; };

4.5 常见的接口联调场景记录

我把平时联调中遇到的高频场景整理成一个表，方便大家直接对号入座：

5. 实测复盘：一次订单号显示错误的完整排查链路

讲完了理论和方案，我来复现一次实际排查过程。这是我在一个电商后台系统里遇到的真实问题，现象是：订单列表页的订单号显示正确，点击详情页后偶尔会出现订单号不一致，刷新几次又正常了。这种随机性特别让人抓狂。

5.1 第一步：确定前端拿到的原始JSON

打开浏览器开发者工具，找到详情页的接口请求，查看响应结果。这一步非常关键，如果原始JSON里就已经是错误的值，问题在后端；如果原始JSON是正确的字符串，问题在前端。

我当时看到的是：

{ "orderId": 9007199254740992, "orderNo": "202501150001234567" }

orderId是数字类型，而且末位是...920，明显丢了精度。这就直接排除了前端的问题，因为前端在JSON.parse之前不会修改原始值。

5.2 第二步：直连后端服务，绕过网关

在服务器上用curl直连后端服务，看原始响应：

curl http://127.0.0.1:8080/api/order/detail/123

返回：

{ "orderId": 9007199254740992, "orderNo": "202501150001234567" }

直连也出错，说明网关没问题，问题出在后端服务本身。

5.3 第三步：检查后端实体类和序列化配置

打开后端代码，找到订单实体类：

public class Order { private Long orderId; private String orderNo; }

果然，orderId是Long类型，而且项目里没有配置全局ToStringSerializer。所以Jackson序列化时，直接把这个Long输出成了数字。前端JSON.parse的时候就丢了精度。

这里有个细节：列表页为什么显示正确，详情页却错误？因为列表页的接口返回的orderId恰好没有超出安全范围（比如还在16位以内），而详情页的数据是另一条，刚好超了。或者反过来，列表页做了一次字符串格式化，详情页没有。总之，是否触发丢精度，完全取决于具体ID的数值大小，这也就是为什么"偶尔出错"。

5.4 第四步：修复并验证

我采用的方案是后端全局配置ToStringSerializer，因为项目里Long类型的字段基本都是ID类的，没有统计数量和时间戳字段，所以做全局配置影响可控。

@Configuration public class JacksonConfig { @Bean public Jackson2ObjectMapperBuilderCustomizer jacksonCustomizer() { return builder -> { builder.serializerByType(Long.class, ToStringSerializer.instance); builder.serializerByType(Long.TYPE, ToStringSerializer.instance); }; } }

重启服务，再次curl：

{ "orderId": "9007199254740993", "orderNo": "202501150001234567" }

前端无需改动，展示恢复正确。

5.5 遗留的隐患与复盘

修复完成后，我又检查了其他使用Long的场景，发现有两个接口的Long字段是业务统计数值，比如订单总金额（单位是分）。把Long全局转字符串后，前端拿到的是字符串，但前端在计算总金额时直接用了Number()转换，结果又丢精度了。

后来我把这两个字段单独用Integer或者BigDecimal接收，就不会被全局配置影响了。

注意：全局配置ToStringSerializer是一把双刃剑。它解决了ID精度问题，但可能会影响业务代码中对数字字段的运算逻辑。在配置前，务必全项目搜索确认Long类型字段的使用场景。

6. 边界情况与疑难杂症：这些"意外"比主问题更坑

当你解决了"后端Long转字符串"、"前端BigInt解析"这些主流问题之后，往往会遇到一些更加隐蔽的边角情况。这些情况如果不提前排查，上线后照样会炸。

6.1 不是所有"超长整数"都是ID，别一刀切

最典型的是时间戳。很多系统的时间字段就是用Long存的毫秒值，比如：

{ "createTime": 1737000000000, "expireTime": 1737003600000 }

毫秒级时间戳是13位，还在安全范围内，不会丢精度。但微秒级时间戳是16位，比如1737000000000000，就已经踩到安全边界了。如果后端把这些字段也全局转成字符串，前端的日期格式化函数就全得跟着改。

所以做全局序列化配置之前，务必先列举出项目里所有Long字段，分类讨论：

• 主键/外键类：转字符串。
• 时间戳类：改成Date类型返回，或者明确告诉前端是数字还是字符串。
• 金额类（分、厘）：用BigDecimal，不要用Long。
• 计数类：一般不会超安全范围，保持数字类型。

6.2 BigInt与JSON.stringify的"不兼容"

前端用BigInt处理大整数时，会遇到一个很蛋疼的问题：JSON.stringify({ orderId: 9007199254740993n })会直接抛异常。

const big = BigInt("9007199254740993"); JSON.stringify({ orderId: big }); // TypeError: Do not know how to serialize a BigInt

这不是bug，是语言设计时就留下的坑。解决办法是给对象提供一个toJSON方法：

const bigObj = { orderId: BigInt("9007199254740993"), toJSON() { return { orderId: this.orderId.toString() }; } }; console.log(JSON.stringify(bigObj)); // {"orderId":"9007199254740993"}

或者在序列化前统一转字符串。总之，BigInt是计算层面的工具，不是传输层面的类型，别拿它直接怼到JSON.stringify里。

6.3 前端比较运算的隐式转换陷阱

还有一种场景，后端两个接口分别返回了字符串形式的ID，比如orderId: "9007199254740993"，前端要做两个ID是否相等的判断：

const id1 = "9007199254740993"; const id2 = "9007199254740992"; console.log(id1 === id2); // false，正确

但如果你在判断前不小心用了==：

console(id1 == id2); // false，仍然正确

其实字符串比较本身没问题，真正需要注意的是后端时而是字符串、时而是数字的情况，这种"类型漂移"最容易引发隐蔽的bug。比如接口在正常返回时给的是字符串，但在某个异常分支里返回的是数字，前端===比较就会失效。

解决方案是前端写一个统一处理函数，在数据入口处就把ID类的值全部转成字符串：

const normalizeIds = (data) => { if (Array.isArray(data)) return data.map(normalizeIds); if (data && typeof data === 'object') { const result = {}; Object.keys(data).forEach((key) => { if (/Id|No|Sn|Code$/i.test(key) && data[key] !== null && data[key] !== undefined) { result[key] = String(data[key]); } else { result[key] = normalizeIds(data[key]); } }); return result; } return data; };

6.4 前端表格组件、图表库的大数显示问题

再说一个经常被忽视的场景：表格组件和图表库。

很多前端UI框架（比如Element Plus的Table组件）在列配置里支持formatter，但如果你把ID字段直接绑定了prop，组件默认会将值原样渲染，字符串就是字符串，数字就是数字，看起来没啥问题。

但如果你用了某些图表库（比如ECharts），在tooltip里显示ID时，图表库可能会对数据进行一次类型转换，或者为了性能优化把数字转成了科学计数法。比如9.007199254740992e+15，这种显示在界面上非常奇怪。

解决方案还是那句话：接口层就返回字符串，前端不要试图转数字。

6.5 微服务架构下的"跨服务传递"

微服务环境下，服务A返回给服务B的JSON，B在反序列化时也可能丢精度。比如服务A给服务B传了一个Long类型的orderId，B用Jackson反序列化成自己的实体类Long orderId。Jackson把一个JSON数字转成Java的Long是没问题的，但如果是JS前端直接调服务B的接口，那又回到了老问题。

另外一个隐蔽的点是消息队列。服务A发消息给Kafka/RabbitMQ，消息体里如果带了超长整数，消费者服务反序列化时同样可能丢精度（取决于消息格式是JSON还是Avro）。所以消息体里也建议统一转字符串。

我之前在处理一个订单状态流转的流水线时，就因为Kafka消息里的orderId是数字类型，中间有一个Python写的消费者处理完后，再发消息给Java服务，Java服务里的orderId就已经不是原始值了。排查了整整一天，最后发现是Python消费者在json.loads时，把数字原样保留，然后json.dumps又输出数字，虽然Python自身不丢精度，但Java消费者用Long接收时还是准确的，问题是出在前端展示环节。链路越长，越要每一环都约束类型。

6.6 前端"看似正常"但实际已越界的大数展示

最后分享一个我见过最迷惑的bug。某个管理系统里，用户ID已经超了16位，但页面显示一切正常，ID完整展示出来了，没有变成科学计数法，也没有出现...00结尾。为什么？

排查后发现，后端返回的是字符串，前端展示也是字符串，一切正常。但问题出在一个导出Excel的功能上。导出Excel时，前端把数据传给后端，后端生成Excel，用户打开Excel看到的ID是科学计数法。这是因为Excel本身对超过15位的数字就会自动转成科学计数法。

这不是JavaScript的问题，也不是后端JSON的问题，而是Excel的显示机制。处理方案是在导出时，把ID列设置为文本格式，或者在后端导出Excel时在ID前加一个'前缀（Excel的强制文本标记）。

这类"看似解决了"的边界问题，往往比主问题更考验经验。

7. 项目落地建议与个人心得

最后聊一些我自己的体会，这部分不一定每个项目都适用，但应该能帮大家少走弯路。

7.1 新项目：从数据库字段设计就开始防

如果你是新建项目，强烈建议在数据库设计阶段就把这个问题考虑进去：

• 主键：尽量用varchar(64)或者bigint unsigned，如果是bigint，接口层必须全局转字符串。
• 业务单号：用字符串类型，格式统一（比如前缀+日期+流水号），避免纯数字。
• 唯一标识：如果使用了雪花算法之类的分布式ID生成器，接口层统一序列化为字符串，不要裸露数字给前端。

数据库层面一个字段类型的选择，决定了后面所有链路要不要跟这个bug作战。

7.2 老项目：寻找"改动最小、覆盖最全"的平衡点

老项目改造最忌讳大动干戈。如果你只是想解决现阶段暴露的问题，推荐按这个顺序操作：

1. 后端全局配置Long转字符串（如果影响面可控）。
2. 前端axios响应拦截器里，对所有ID字段做字符串强制转换（防后端遗漏）。
3. 前端JSON解析用json-bigint兜底（防第三方接口或者老接口数字类型返回）。
4. 在接口文档里明确注明ID字段类型为string，并推动前后端联调时按string处理。

这套组合拳下来，基本能覆盖90%以上的场景。

7.3 团队协作层面：定一个"ID传输规范"

我见过很多团队因为这个问题反复扯皮，前端说是后端的问题，后端说是前端的问题。最终能彻底解决的，都是靠一份明确的接口文档规范：

• 所有ID类字段（主键、外键、业务单号、流水号），声明为string类型。
• 所有时间戳字段，声明为string或number并注明单位。
• 所有金额字段，声明为string（元/分）并注明精度。
• 禁止后端返回超过Number.MAX_SAFE_INTEGER的数字类型字段。
• 禁止前端对ID类字段做Number()转换。

规范这种东西，平时看起来没人认真看，但真的能在关键时刻救命。特别是团队扩张、新同学入职的时候，一份清晰的规范能避免很多无意义的争吵。

7.4 最后的最后：一个实用小技巧

如果你正在调试一个疑似精度问题，但又不确定是哪个环节丢了精度，有一个超简单的验证方法：

// 在浏览器控制台直接输入 Number.isSafeInteger(9007199254740993) // false Number.isSafeInteger(9007199254740992) // true

在Node.js里也可以验证后端接口返回的JSON是不是安全的：

node -e "console.log(Number.isSafeInteger(JSON.parse('9007199254740993')))"

通过这个Number.isSafeInteger方法，你可以快速判断当前值是否已经触发精度丢失。这个函数在实际调试时比肉眼盯着数字看要靠谱得多。

16位数字精度问题，说大不大，说小不小。踩过坑的人会条件反射地在接口层处理类型；没踩过坑的人，可能直到上线那天被用户截图投诉才会意识到问题的严重性。希望这篇复盘能帮大家把这个坑提前填上。