《长得太长也是错？——后端 Long 型 ID 精度丢失的“奇妙”修复之旅》

原创

繁依Fanyi 2025-06-13 11:21:51 ©著作权

文章标签 字符串序列化 xml 文章分类 JavaScript 前端开发

©著作权归作者所有：来自51CTO博客作者繁依Fanyi的原创作品，请联系作者获取转载授权，否则将追究法律责任

引言

在前后端分离的时代，我们的生活充满了无数的机遇与挑战——包括那些突然冒出来的让人抓狂的 Bug。今天我们要聊的，就是一个让无数开发者哭笑不得的经典问题：后端 Long 类型 ID 过长导致前端精度丢失。说到这个问题，那可真是“万恶之源”啊，谁让 JavaScript 只能安全地处理 Number.MAX_SAFE_INTEGER（也就是 9007199254740991）以内的数值呢？

如果你曾经为了这个问题而冥思苦想，别担心，你不是一个人。今天，我们不仅要用幽默的方式来剖析这个“世纪难题”，还要带你从根源上解决它，让你的代码不再“失精”。

问题背景：为什么 Long

首先，我们得从 Long 类型说起。Long，就是 Java 中的 64 位整数类型，对于喜欢处理大数据、大数字的 Java 来说，这个类型简直就是福音。然而，前端世界却有点“孤陋寡闻”，它只懂得处理 53 位以内的整数。是的，你没听错，在这点上 JavaScript

第一次相遇：精度丢失的那些事

故事得从某一天的 Bug 反馈开始：“开发哥哥，你看这个 ID 怎么变了样？这不是我数据库里的那个 ID 啊！”你皱着眉头一看，是的，9223372036854775807 变成了 9223372036854776000，哎呀，这多出来的数字简直像是魔术一样。明明后端给的是对的呀！你一边抓头一边心想：“这肯定是前端的锅！”

前端的锅还是后端的锅？——追根溯源

其实吧，这个问题甩锅给前端也不是完全没道理。让我们来看看 JavaScript 在处理数字时的“短板”。JavaScript 的 Number 类型是基于 IEEE 754 标准的双精度浮点数格式，只能安全地表示 53 位二进制数字，也就是 Number.MAX_SAFE_INTEGER换句话说，超过这个范围的整数，JavaScript 就会开始“精度打折”，它的“脑容量”突然就不够用了。于是，你的 Long

从震惊到冷静：寻找解决方案

既然问题的根源已经找到，那就轮到我们这些开发者来大显身手了。接下来，我将带你深入了解几种解决方案，并告诉你每种方案的优缺点，毕竟条条大路通罗马。

1. 直接转成字符串：简单粗暴却高效

面对这种问题，我们最先想到的肯定是最简单粗暴的方法：直接把 Long 类型的数据转换成字符串不就好了嘛！既然 JavaScript如何做到这一点呢？其实很简单，使用 Jackson 提供的 ToStringSerializer，我们可以轻松地把 Long

登录后复制

import com.fasterxml.jackson.databind.annotation.JsonSerialize;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;

public class UserDto {
    @JsonSerialize(using = ToStringSerializer.class)
    private Long id;
    // 其他字段
}

这样一来，当后端返回 UserDto 的时候，Long 类型的 id

2. 前端使用 BigInt：让大数也能精确运算

当然，简单粗暴的方法并不总是适合所有场景。想象一下，如果前端需要对这个 ID 进行某种数学运算，直接转成字符串可就不太好了。那么，前端该怎么处理这些“超长”的 ID 呢？

幸运的是，JavaScript 也不是一无是处。引入了 BigInt 之后，JavaScript 终于不再是那个只会摆弄小数点的呆子了。BigInt

登录后复制

const id = BigInt("9223372036854775807");
console.log(id + 1n); // 输出：9223372036854775808n

这样，你就可以在前端精确地处理 Long 类型的数据，避免精度丢失的问题。当然，这里有一个小小的提醒：BigInt

3. 自定义序列化：复杂问题简单化

虽然上面的方法已经可以解决大多数问题，但有时候我们会遇到一些需要更细粒度控制的场景。这时候，Jackson我们可以编写一个自定义的序列化器，根据需求灵活控制 Long 类型字段的序列化过程。比如，我们可以在序列化时决定是否将 Long

登录后复制

import com.fasterxml.jackson.core.JsonGenerator;
import com.fasterxml.jackson.databind.JsonSerializer;
import com.fasterxml.jackson.databind.SerializerProvider;

import java.io.IOException;

public class CustomLongSerializer extends JsonSerializer<Long> {

    @Override
    public void serialize(Long value, JsonGenerator gen, SerializerProvider serializers) throws IOException {
        if (value != null) {
            gen.writeString(value.toString());
        }
    }
}

然后在需要的地方应用这个自定义序列化器：

登录后复制

import com.fasterxml.jackson.databind.annotation.JsonSerialize;

public class UserDto {
    @JsonSerialize(using = CustomLongSerializer.class)
    private Long id;
    // 其他字段
}

这样，你就能掌控整个序列化过程，确保每一个 Long

4. 全局处理：省时省力的方案

如果你希望全局解决这个问题，省去在每个字段上配置注解的麻烦，可以考虑全局配置 ObjectMapper。通过在 Spring Boot 中配置全局的 ObjectMapper，你可以让所有的 Long

登录后复制

import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.module.SimpleModule;

@Configuration
public class JacksonConfig {

    @Bean
    public ObjectMapper objectMapper() {
        ObjectMapper mapper = new ObjectMapper();
        SimpleModule module = new SimpleModule();
        module.addSerializer(Long.class, ToStringSerializer.instance);
        module.addSerializer(Long.TYPE, ToStringSerializer.instance);
        mapper.registerModule(module);
        return mapper;
    }
}

一劳永逸，不用担心忘记某个字段配置序列化器，整个项目都能享受到精度不丢失的快感。当然，使用全局配置的同时要注意，可能会影响到某些你不希望被转换的 Long