Bug:Long类型前后端传递数据不一致解决方案

本文探讨了在前后端分离项目中,由于雪花算法生成的17位Long ID与JavaScript Number类型冲突导致的问题。通过配置Springboot、转换数据类型及使用fastJSON,作者提供了有效解决方案,并分享了避免精度损失的技巧。

问题描述:

本人最近在写一个前后端分离项目,后端实体类中的id字段使用Long类型,来对应数据库bigint类型的主键。同时使用雪花算法自动生成17位数字的id。
(注:雪花算法,生成指定位数不重复的Long值,来作为主键的id)
然后前端获取id时,与后端传入的id不一致。


原因分析:

分析:查阅相关资料,发现前端中js的Number类型最大值为9007199254740991(16位数),一旦超过这个值,就会发生精度缺失现象。本文中的雪花算法产生的id为92625918782214144(17位数),明显大于Number类型的最大值,因此前后端数据传递发生错误,导致前端接收到的与后台传入的不一致。

注:js中Number类型最大值:9007199254740991(16位数)
java中Long类型最大值:9223372036854775807(19位数)
本项目中id的值均为 17位数,因此符合Long类型,不符合Number类型。
因此本项目中的id会产生四舍五入的现象。
我的项目中 我真实的id为 92625918782214144
前端接收的为 92625918782214140


解决方案:

解决方案1(亲测有效)

Springboot项目,在配置文件中添加一句即可。

spring.jackson.generator.write_numbers_as_strings = true

后端还是使用Long类型,前端使用Number接收。

解决方案2

实体类中,id字段不使用Long类型,改为String类型即可。

    //private Long id;
    
    private String id;

不推荐,这样的话你的数据库主键就不能使用bigint类型了,得使用varchar类型,varchar类型作为主键的话加大消耗,降低了索引效率。

解决方案3

使用alibaba的fastJSON工具包(需要引入依赖)
实体类中,在Long类型的字段上加@JsonSerialize(using = ToStringSerializer.class)
这样就能在序列化时自动将该字段类型转为String类型返给前端

@Data
public class Ebook {

    @JSONField(serializeUsing= ToStringSerializer.class)
    private Long id;

    private String name;

或者 不要设置超过16位的Long类型就OK啦。

总结

目前就找到这么多,工作之余记录一下自己遇到的坑。如有不足,欢迎指正。

评论 6
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值