【踩坑经历】Java Long 类型传给前端损失精度的问题

最近在做一个 SpringBoot + Vue 的项目，持久层框架用的是 MyBatis-Plus，然后遇到了一个问题，一起来看下怎么回事。

这个项目就是一个文章收藏器，可以收藏一些技术文章，然后可以选择星标，以便查找这篇文章。

那么点击星标的按钮，实际上就是调了后端一个接口，更新了数据库中相应字段。每一个列表的字段如下：

可以看到，标记星标的字段就是 isFavorite ，没有星标的时候是 0 ，星标之后变成 1 。同时这边还有个 id 字段，这个字段是由 MyBatis-Plus 插入数据库时自动填充的，是一个 Long 类型的 uuid 。在调接口的时候，后台根据传过来的 id 进行条件更新。

但是在测试的时候，调接口发现 isFavorite 一直更新失败，但是SQL 语句正常执行，没有报错，看一下打印的 SQL 语句：

然后 Controller 层的逻辑是这样写的：

@PutMapping
public ResponseEntity<ServerResponse> changeFavoriteStatus(
        @NotBlank(message = "文章 ID 不能为空") @RequestParam("articleId") String articleId,
        @NotBlank(message = "星标状态不能为空") @RequestParam("isFavorite") String isFavorite
) {
	LambdaUpdateWrapper<ArticleModel> updateWrapper = new LambdaUpdateWrapper<>();
    updateWrapper
            .eq(ArticleModel::getId, Long.valueOf(articleId))
            .set(ArticleModel::getIsFavorite, Integer.valueOf(isFavorite));
	articleMapper.update(null, updateWrapper);
    return ServerResponse.ok(null);
}

这就有点头疼了，关键没有报错，无从下手啊。假如是 MyBatis-Plus 提供的 API 有问题，应该会有报错信息。然后网上查了很多资料，看别人的代码都是跟我一样写的，但是也没看他们遇到这样的问题。

后来尝试硬编码，直接在代码里面填写参数，发现可以更新成功：

@PutMapping
public ResponseEntity<ServerResponse> changeFavoriteStatus(
        @NotBlank(message = "文章 ID 不能为空") @RequestParam("articleId") String articleId,
        @NotBlank(message = "星标状态不能为空") @RequestParam("isFavorite") String isFavorite
) {
	LambdaUpdateWrapper<ArticleModel> updateWrapper = new LambdaUpdateWrapper<>();
    updateWrapper
            .eq(ArticleModel::getId, 1404788380714967042L)
            .set(ArticleModel::getIsFavorite, 1);
	articleMapper.update(null, updateWrapper);
    return ServerResponse.ok(null);
}

这样一下就有了思路，因为我这边的 id 是直接数据库复制过来的，那么基本可以确定是前端传过来的 id 有问题。看一下查询接口打印的 SQL 语句：

看到第一条记录的 id 字段是 1404788380714967042 。然后再来看一下传给前端的字段，发现确实不一样：

综上，本人再查询了相关资料，Java 中 long 数据类型是 64 位，最大值是 9,223,372,036,854,775,807 ，也就是 2^63 - 1 ，然后 JavaScript 中的 number 类型，最大的安全整数 2^53 - 1 。

也就是说，Java 中的 Long 类型能表示的范围比 JS 的 number 类型大，如果后端在序列化的时候直接用 Long 类型，前端在反序列化的时候，number 会损失精度，导致 id 字段不是实际的 id ，进而查询不到记录，无法更新。因此对于 Long 类型，后端需要转为字符串才能传给前端。

转为字符串的话，常规的做法是定义一个 DTO 类，将 Long 类型的字段都定义成 String ，那么这样的做法比较麻烦，而且如果接口有很多，需要大量的 DTO 。另一种做法是使用注解，在序列化的时候保留精度。

SpringBoot 默认使用的 JSON 解析框架是 jackson，可以直接使用。如果要用第三方框架，例如 fastjson 则需要进行配置。以 jackson 为例，对于在序列化时需要保留精度的字段，添加 @JsonSerialize 注解即可：

@Data
@TableName("tb_article")
public class ArticleModel {
    @JsonSerialize(using = ToStringSerializer.class)
    private Long id;

    private Integer isFavorite;
}

在添加注解之后，前端拿到的参数如下，可以看到 Long 类型 id 变成字符串了：

另外这边还有一个时间戳，没有转为字符串，本人认为没有必要，因为 JS 里面本身也有时间戳哈，而且这个范围没有超出 number 的最大安全整数，可以直接用。另外 jackson 还提供了注解可以在序列化时自定义格式化：

@Data
//序列化、反序列化忽略的属性，多个时用“,”隔开
@JsonIgnoreProperties({"captcha"})
//当属性的值为空（null或者""）时，不进行序列化，可以减少数据传输
@JsonInclude(JsonInclude.Include.NON_EMPTY)
public class UserVoByJson {

    // 序列化、反序列化时，属性的名称
    @JsonProperty("userName")
    private String username;

    // 为反序列化期间要接受的属性定义一个或多个替代名称，可以与@JsonProperty一起使用
    @JsonAlias({"pass_word", "passWord"})
    @JsonProperty("pwd")
    private String password;

    //序列化、反序列化时，格式化时间
    @JsonFormat(locale = "zh", timezone = "GMT+8", pattern = "yyyy-MM-dd HH:mm:ss")
    private Date createDate;

    //序列化、反序列化忽略属性
    @JsonIgnore
    private String captcha;

}

参考：
java long类型报错：error: integer number too large
java的long类型传输到前端损失精度
Springboot引入FastJson
修复Long类型太长，而Java序列化JSON丢失精度问题的方法
Number.MAX_SAFE_INTEGER - MDN
SpringBoot系列——Jackson序列化