一个诡异的现象
在进行数据结构设计时，我们通常需要考虑到相关业务的数据量等因素。比如非核心业务但数据量大并且频繁写入的表的主键，我们可能会考虑设计为Long类型。刚开始，数据量小，可能并不会发现什么问题。但是当数据量大了，或者Id采用雪花算法生成，这个时候诡异的事情便会发生。
后端数据正常返回，postman调试看数据也正常。但是当前端用后端返回的这个id查询相应的数据时，便会发生诡异的NotFoundException，或者查询的出来的数据和原先的数据不一致。
所以，谁偷偷动了我的代码？
JavaScript的数值精度
如果只从后端分析问题，或者只从前端分析问题，那永远也找不到答案。
在 JavaScript 中，数值类型默认会被转换为双精度浮点数，而双精度浮点数的精度有限，只能精确表示 2 的 53 次方以内（即 Number.MAX_SAFE_INTEGER，约为 9 x 10^15）的整数。对于超过该范围的长整数，JavaScript 会发生精度丢失，导致值变得不准确。
例如一个雪花算法生成的ID 1734042308679487490，前端获取到的值却变成了1734042308679487500
知道了问题的原因，问题就容易解决了——将Long类型作为String类型返回给前端即可。
一个简单的解决办法
(1) Spring Boot 中提供了 @JsonFormat 注解，可以对实体类中的属性进行序列化和反序列化格式化。对于 Long 类型的属性，可以设置其格式为字符串类型，并在前端进行相应的处理，以保持其精度不丢失。如：
public class Order {
@JsonFormat(shape = JsonFormat.Shape.STRING)
private Long id;
...
}前端获取到的是string类型的数据，自然也不会有精度丢失的问题了。
(2) SpringBoot也支持在通过配置文件在项目级别，将数值类型的数据转成字符串返回给前端，通过在 application.properties 文件中添加配置即可:
# 默认为false
spring.jackson.seralization.WRITE_NUMBER_AS_STRINGS=true(3) 如果不想使用 @JsonFormat 注解或者项目不是基于SpringBoot框架构建的，同样的思路，直接将Long类型转换成String返回给前端即可。
总结
在 JavaScript 中数值类型最大精度大约为9*10^15，即超过16位的数值一定会存在精度丢失问题。因此，后端返回Long类型的数值时，需要转换成String给到前端。
