在前后端分离的开发架构下你是否遇到过这样一个令人抓狂的场景：后端日志里明明打印着数据库主键ID是 1359210084236800001，可到了前端控制台，这个数字却诡异地变成了 1359210084236800000？geng糟糕的是当前端拿着这个被“篡改”过的ID去请求详情页或者执行删除操作时后端毫不留情地抛出“数据不存在”的异常。

这种时候，作为后端开发，心里往往是万马奔腾。我明明传的是对的，怎么到你那边就变了？其实这并不是前端的锅，也不是后端的错，而是两个编程语言在“谈恋爱”时由于性格不合而产生的必然矛盾。今天我们就来深扒一下这个经典的技术痛点，并给出一个一劳永逸的解决方案。

要解决问题，得先搞清楚问题的本质。这个问题的根源，其实在于 Java 和 JavaScript 对于数字的处理机制存在天然的差异。

在后端的世界里Java 的 Long 类型是一个 64 位的有符号整数。它的取值范围大得惊人，从 -9,223,372,036,854,775,808 到 9,223,372,036,854,775,807。对于绝大多数业务场景，尤其是使用了雪花算法生成的分布式 ID，通常dou是 19 位左右的长整型，这在 Java 眼里根本不算事儿，存得下算得准，稳如泰山。

然而当这些数据跨越网络传输，来到前端 JavaScript 的世界时情况就变得微妙了。JavaScript 中并没有专门的整数类型，它所有的数字，统统dou是 IEEE 754 标准的双精度浮点数。

这就导致了一个致命的限制：JavaScript Neng安全表示的Zui大整数是 $2^{53}-1$，也就是 9007199254740991。一旦超过这个数值，JS 的精度就会像断了线的风筝一样失控。对于超过 53 位的二进制精度，JS 为了存储，不得不“忍痛割爱”，丢弃低位的数据。

于是当后端那个 19 位的雪花 ID 传过来时因为远远超过了 $2^{53}$，JS 就会自动进行“四舍五入”或者直接将后几位变成 0。这就是为什么你kan到的 ID 总是Zui后几位不对劲。这就像你让一个只Neng写 10 个字的小学生去抄写一篇 1000 字的文章，他只Neng大概记个轮廓，细节全丢了。

既然知道了原因，那怎么解决呢？Zui直观的想法，也是Zui“笨”的办法，就是手动改类型。

hen多新手开发者在遇到这个问题时第一反应是：“那我把后端 DTO 或者 VO 类里的 ID 字段类型从 Long 改成 String 不就行了吗？”

确实字符串在 JS 里是绝对安全的，不会发生精度丢失。但是试想一下一个稍微大一点的项目，DTO、VO、Entity 类加起来可Neng有几百个。Ru果每个涉及 ID 的类dou要你去手动把 Long 改成 String，还要去调整数据库映射逻辑，这不仅工作量巨大，而且容易漏改，甚至可Neng影响到后端业务逻辑中对 ID 的数值运算。

这种“人肉”修改的方式，不仅效率低下而且极不优雅。作为追求极致的程序员，我们怎么Neng容忍这种机械重复的劳动呢？

既然不想一个个改，那就利用框架的威力来“偷懒”。在 Spring Boot 项目中，我们默认使用 Jackson 作为 JSON 序列化工具。我们完全Ke以通过配置 Jackson 的序列化机制，让它在把 Long 类型转 JSON 的时候，自动帮我们转成 String。

这种方案的好处是：你不需要手动去改每一个 DTO 或 VO 类，只需要在 Spring Boot 中加一个全局配置类，一劳永逸地解决问题。

通过配置 Jackson，我们Ke以让所有 Long 类型字段在序列化时自动变成字符串。这样，前端接收到的是 JSON 字符串格式的 ID，虽然kan起来是数字，但本质是文本，完美避开了 JS 的数字精度陷阱。而后端内部处理时依然使用高效的 Long 类型，互不干扰。

下面我们直接上代码。我们需要创建一个配置类，定制 ObjectMapper 的行为。

直接在你的项目 config 包下新建一个类，比如叫 JacksonConfig。这里我们利用 Jackson2ObjectMapperBuilderCustomizer 来进行定制，这是 Spring Boot 推荐的方式。

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.module.SimpleModule;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;
import org.springframework.boot.autoconfigure.jackson.Jackson2ObjectMapperBuilder;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder;
/**
 * @author YourName
 * @description: Jackson全局配置，解决Long类型精度丢失问题
 */
@Configuration
public class JacksonConfig {
    /**
     * 描述: 统一配置类型的转换策略
     * 这里我们利用 Jackson2ObjectMapperBuilderCustomizer 来注入自定义逻辑
     */
    @Bean
    public Jackson2ObjectMapperBuilderCustomizer jackson2ObjectMapperBuilderCustomizer {
        return builder -> {
            // 创建一个自定义的序列化模块
            SimpleModule module = new SimpleModule;
            // 核心代码：将 Long 类型和 long 类型序列化为字符串
            // ToStringSerializer.instance 会调用对象的 toString 方法
            // 这样无论是数据库的主键 ID，还是其他的 Long 字段，dou会变成字符串传给前端
            module.addSerializer;
            module.addSerializer;
            // 将模块注册到 ObjectMapper 构建器中
            builder.modulesToInstall;
        };
    }
}

或者，Ru果你喜欢geng直接一点的控制，也Ke以使用 @JsonComponent 注解来直接定制 ObjectMapper，效果是一样的，殊途同归。

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.module.SimpleModule;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;
import org.springframework.http.converter.json.Jackson2ObjectMapperBuilder;
import org.springframework.stereotype.Component;
/**
 * Spring MVC全局Json配置
 * 用于解决 Long 类型精度丢失问题
 */
@JsonComponent
public class JsonConfig {
    /**
     * 全局配置：将 Long 类型序列化为 String
     */
    public ObjectMapper jacksonObjectMapper {
        ObjectMapper objectMapper = builder.createXmlMapper.build;
        // 创建自定义序列化模块
        SimpleModule module = new SimpleModule;
        // 将 Long 类和 longdou序列化为字符串
        // ToStringSerializer.instance 会调用对象的 toString 方法
        module.addSerializer;
        module.addSerializer;
        // 注册模块
        objectMapper.registerModule;
        return objectMapper;
    }
}

加上这段代码后重启你的 Spring Boot 应用。你会发现，之前那些让你头疼的 ID 精度丢失问题，瞬间烟消云散。前端拿到的 ID 变成了类似 "1359210084236800001" 的字符串形式，虽然多了个引号，但数据是完整的，操作是安全的。

当然作为一个负责任的全栈思维开发者，我们也得聊聊前端NengZuo什么。

虽然后端改成 String 是Zui稳妥的方案，但有时候Ru果后端接口Yi经定型，改不动怎么办？前端也有自己的“自救”措施。比如使用 json-bigint 这样的第三方库，或者是在 Axios 的 transformResponse 里Zuo手脚。不过这些方法往往增加了前端的复杂度，而且容易遗漏。

相比之下后端统一配置成 String 返回，是成本Zui低、风险Zui小的方案。毕竟数据源头治理好了下游自然就顺畅了。

Web 开发中，我们经常遇到前后端数据类型不匹配的问题，特别是当后端使用大数据类型如 Long 时前端由于 JavaScript 的数字精度限制，可Neng导致精度丢失。这不仅仅是显示错误，geng会导致业务逻辑的崩溃。

通过在 Spring Boot 中配置 Jackson 的 ObjectMapper，将 Long 类型全局序列化为 String，我们Ke以优雅地解决这个痛点。不需要去修改每一个 DTO，也不需要前端配合Zuo特殊处理，只需要几行配置代码，就Neng让整个项目的数据传输变得安全可靠。

理解这一处理办法对于前端和后端开发者而言dou非常重要，因为这涉及到数据类型在不同编程语言中的表现以及如何在序列化和反序列化过程中保持数据的准确性。下次再遇到 ID 变成 0 的情况，别再怀疑人生了把这段代码贴进去，问题迎刃而解。