Java列表查询Long(id)到前端转换出错

问题描述

做了一个列表查询功能，本来不应该有啥大问题的，但是往往事与愿违。
诶，你越觉得不可能出问题，他就越出问题了😬，就是玩。
报了一个“Duplicate keys detected: ‘7918899278313947000’”的问题，ID重复了？
我打开F12一看，卧槽！！！真的重复了🤨
重复了那就找问题呗😮‍💨

排查思路

思路一：SQL问题

像这种主键重复第一反应就是是不是SQL写的不对，尤其是多表关联插叙。
于是排查了一顿SQL，发现没啥问题啊，巴对🫤
直到返回前端的page对象中，ID都是不重复的。
但是到了前端之后ID就变一样了🤔这。。。。

思路二：Long类型转换出错

经过对比发现一个问题，就是前16位是一样的，后3位都变成0了。😯😮
于是又有了一个想法，就是在数据传输的过程中，Long类型转化出错了，导致后三位都变成0了。

那就朝着这个方向继续努力💪💪💪

考大家基础知识的时间到了。

Java的八大基本数据类型
整型：byte(1字节8bit)、short(2字节16bit)、int(4字节32bit)、long(8字节64bit)
字符型：char(2字节16bit)
浮点型：float(4字节32bit)、double(8字节64bit)
布尔型：boolean(仅有两个值true, false，变量初始化默认值false

在Java中，long类型是一种表示大整数的数据类型。它使用64位（8字节）的存储空间，可以表示的整数范围从-9223372036854775808到9223372036854775807。

long类型的长度最长为19，刚好数据库id字段的长度就是19😔，但是可以看到显然还不到最大值，如果超过最大值数据入库的时候就会报错，也不会成功入库😓

但是还有一个long类型的字段长度为16，传到前端后数据一致🤨，这是不是说明long类型达到19后会出现意想不到到的错误，导致值发生变化，那就简单粗暴一点，在后端直接转化成String类型就好了😁。

解决方法

找到实体类，在id的字段上fastjson的@JSONField注解转化成字符串就OK了。

import com.alibaba.fastjson.annotation.JSONField;
import com.alibaba.fastjson.serializer.ToStringSerializer;
1
2

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

。
问题解决！！！😀😄😆
打完收工！