以Google浏览器为例说明
一、问题与分析回溯
1、MySQL中表t_user的主键(id)设计为bigint(20)
2、实体类中的id设计如下
@TableId(type= IdType.ID_WORKER_STR)
public Long id;
3、当需要生成UUID（均为17位）时，使用的方法如下
@Mapper
public interface CommonMapper {
// 返回Long型UUID
@Select("SELECT UUID_SHORT()")
Long getShortUUid();
}
// 返回String类型的UUID
@Select("SELECT UUID_SHORT()")
String getShortStrUUid();
4、当分页查询该表(t_user)时，由于返回的id均为Long型，在前端被处理成Number时，无法根据此不精确的整数查询到正确的结果
5、根本原因
JavaScript的Number类型能表示并进行精确算术运算的安全整数范围为：正负(-1)（16位数），
也即从最小值-9007199254740991到最大值+9007199254740991之间的范围；
对于超过这个范围的整数，JavaScript依旧可以进行运算，但却不保证运算结果的精度。
Google浏览器最大最小整型数值
二、解决办法（方式一）
1、将一.2中的设计修改如下
@TableId(type= IdType.ID_WORKER_STR)
public String id;
对，直接将接收的Long型id修改为String类型，事实证明，使用修改之后的实体接收数据库查询到的数据时，它会自动转为String类型。
2、涉及生成的UUID，在CommonMapper中添加如下
// 返回String类型的UUID
@Select("SELECT UUID_SHORT()")
String getShortStrUUid();
需要生成String类型的UUID时，使用该方法。
三、解决办法（方式二，推荐）
参考后台的long类型的最大值大于js的number类型，此方式侵入最小，已验证，可行！
注解如下
import com.fasterxml.jackson.databind.annotation.JsonSerialize;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;
...
...
@JsonSerialize(using = ToStringSerializer.class)
public Long id;
四、解决办法（方式三，强烈推荐）
import com.fasterxml.jackson.annotation.JsonInclude;
import com.fasterxml.jackson.databind.PropertyNamingStrategy;
import com.fasterxml.jackson.databind.ser.std.ToStringSerializer;
import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.boot.autoconfigure.jackson.Jackson2ObjectMapperBuilderCustomizer;
import org.springframework.context.annotation.Bean;
import org.springframework.context.annotation.Configuration;
@Configuration
public class AppConfig {
@Bean
public Jackson2ObjectMapperBuilderCustomizer customJackson() {
return jacksonObjectMapperBuilder -> {
jacksonObjectMapperBuilder.serializationInclusion(JsonInclude.Include.NON_NULL);
// Jackson全局转换long类型为String，解决jackson序列化时long类型缺失精度问题
// 自定义Long类型转换 超过12个数字用String格式返回，由于js的number只能表示15个数字
jacksonObjectMapperBuilder.serializerByType(Long.class, ToStringSerializer.instance);
// jacksonObjectMapperBuilder.serializerByType(Long.TYPE, ToStringSerializer.instance);
jacksonObjectMapperBuilder.failOnUnknownProperties(false);
jacksonObjectMapperBuilder.propertyNamingStrategy(PropertyNamingStrategy.SNAKE_CASE);
};
}
}
由于如此配置之后，后端中的对象中只要字段类型为Long的，均会被转为String类型，由此可能会造成其他字段报错。如一般我们分页查询，会封装一个实体类，实体类中一般会有总页数参数，一般设置为Integer类型即可，但是如果设置为Long类型，传到前端，就会被上述配置转为String类型，由此造成前端无法解析报错。
其他的还有关于金额的字段，如果后端全部为long类型（分设计）也会出现该问题。
参看 Spring Boot 2.0版本 Jackson全局转化long类型为String，解决jackson序列化时long类型缺失精度问题
