那天前端同事跑过来跟我说，"你那个接口返回的订单ID，更新数据时接口没返回异常，但数据重新查又没更新成功"

我当时第一反应是：不可能，后端查出来是什么就返回什么，肯定是你前端哪里处理出了问题。

然后我打开浏览器F12一看，Network面板里接口返回的JSON里，orderId 的值是 1784523698741256200，而数据库里存的是 1784523698741256193,后端拿1784523698741256200来更新数据确实没报异常。

好家伙，最后几位确实被改了。但问题是，这串数字在Java后端打印日志的时候是完完全全正确的，偏偏到了浏览器这边就变了。

稍微查了一下就明白了。我们后端之前是用的mysql的自增id做主键 设置的为int型，后来为了统一系统主键值 用雪花算法生成主键 设置为了Long，JavaScript里的 Number 类型是双精度浮点数，它能安全表示的最大整数是 2^53 - 1，也就是 9007199254740991。而Java的 Long 最大值是 2^63 - 1，远远超过了JS能精确表示的范围。

所以当后端把一个超出JS安全范围的Long值以数字形式写进JSON，浏览器在解析的时候就会丢精度。这个不是后端的bug，也不是前端的bug，是JavaScript语言本身的限制。

我们项目里的ID基本都是雪花算法生成的，长度在18~19位，妥妥超出 Number.MAX_SAFE_INTEGER，所以只要以数字返回，前端就一定拿不到精确值。

后端在序列化成JSON的时候，把所有Long类型转成字符串。

 这样JSON里的数字就变成了字符串，浏览器解析的时候不会当作Number去处理，精度自然不会丢失。

实现方式有很多种，可以在每个DTO的Long字段上加 @JsonSerialize(using = ToStringSerializer.class) 注解，但这样做太麻烦了，项目里几十个实体类，每个类里可能都有Long字段，一个个加注解纯粹是体力活。

，在消息转换器层面一次性解决。

我们项目里是通过继承 WebMvcConfigurationSupport，重写 configureMessageConverters 方法来实现的。核心代码其实就这么几行：

@Override
public void configureMessageConverters(List<HttpMessageConverter<?>> converters) {
    MappingJackson2HttpMessageConverter jackson2HttpMessageConverter = 
            new MappingJackson2HttpMessageConverter();
    ObjectMapper objectMapper = new ObjectMapper();
    
    // 序列化成json时,将所有的long变成string
    SimpleModule simpleModule = new SimpleModule();
    simpleModule.addSerializer(Long.class, ToStringSerializer.instance);
    simpleModule.addSerializer(Long.TYPE, ToStringSerializer.instance);
    objectMapper.registerModule(simpleModule);
    
    // 前端多传了字段也不报错
    objectMapper.configure(
        DeserializationFeature.FAIL_ON_UNKNOWN_PROPERTIES, false);
    jackson2HttpMessageConverter.setObjectMapper(objectMapper);
    
    converters.add(jackson2HttpMessageConverter);
}


，创建一个 SimpleModule，往里面注册两条序列化规则——Long.class（包装类型）和 Long.TYPE（基本类型 long）都使用 ToStringSerializer。这两个缺一不可，因为有的实体用 Long，有的用 long，少注册一个就会漏掉。

，把这个 SimpleModule 注册到 ObjectMapper 里，这样Jackson在序列化任何Long值的时候都会自动调用 toString()，输出到JSON里就是带引号的字符串。

，把自定义的 ObjectMapper 设给 MappingJackson2HttpMessageConverter，再把它加到转换器列表里。

这里有个细节要注意。如果你用的是实现 WebMvcConfigurer 接口的方式，configureMessageConverters 方法里的配置

。因为 WebMvcConfigurer 的 configureMessageConverters 在Spring Boot某些版本下行为不太一致，自定义的转换器可能被默认转换器覆盖或者追加顺序不对。

我们项目里是直接继承 WebMvcConfigurationSupport，这个方式的优先级更高，配置更可靠。但代价是继承了它之后，Spring Boot关于WebMvc的自动配置就不再完全生效了，所以像静态资源映射、拦截器这些都得自己手动配，项目里也确实都配了：

@Override
public void addResourceHandlers(ResourceHandlerRegistry registry) {
    registry.addResourceHandler("/static/**")
            .addResourceLocations("classpath:/static/");
    registry.addResourceHandler("swagger-ui.html", "doc.html")
            .addResourceLocations("classpath:/META-INF/resources/");
    // ...
}


在同一个方法里，还顺带处理了两件事：

一是把 FAIL_ON_UNKNOWN_PROPERTIES 设成了 false。前端有时候会多传一些字段过来，如果不关掉这个配置，Jackson反序列化时遇到不认识字段就会抛 Unrecognized field 异常，很烦人。

二是加了一个 StringHttpMessageConverter 并且关掉了 WriteAcceptCharset，解决的是访问 actuator/prometheus 接口返回406的问题。

StringHttpMessageConverter stringHttpMessageConverter = new StringHttpMessageConverter();
stringHttpMessageConverter.setWriteAcceptCharset(false);
converters.add(stringHttpMessageConverter);


改完之后重启服务，再看接口返回：

// 改之前
{ "orderId": 1784523698741256193 }

// 改之后
{ "orderId": "1784523698741256193" }


前端拿到的是字符串，精度不再丢失，问题解决。

这个问题说实话不算难，也是个容易复现的问题，但第一次遇到的时候确实容易懵，尤其是排查的时候日志里看到的值都是对的，偏偏前端拿到就是错的，会让人怀疑人生。核心就一句话：

JS的数字装不下Java的Long，让后端序列化成字符串就行了。

全局配置比注解优雅得多，一处配置，全项目生效省心。在这里仅记录一下。

前后端Long精度丢失的踩坑

后端

前端

编程语言

接口返回的雪花算法Long型订单ID超出JavaScript安全整数范围，导致前端获取的数值精度丢失（如1784523698741256193变为1784523698741256200）。解决方案：通过继承WebMvcConfigurationSupport全局配置Jackson序列化，将Long类型转为字符串输出，同时关闭未知字段报错，一次配置全项目生效，有效避免精度问题。

JavaScript

数据库

MySQL

JSON

Java

让每一个 Agent，都跑在云上

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

接口返回的雪花算法Long型订单ID超出JavaScript安全整数范围，导致前端获取的数值精度丢失（如1784523698741256193变为1784523698741256200）。解决方案：通过继承WebMvcConfigurationSupport全局配置Jackson序列化，将Long类型转为字符串输出，同...

前后端Long精度丢失的踩坑

前后端Long精度丢失的踩坑

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐