案例:


核心原因
这个问题是 JavaScript 数字精度丢失导致的 ------ 后端返回的地址 ID(如1996757981109010434)是超过了 JavaScript 安全整数范围(2^53 - 1,即9007199254740991)的大整数,前端接收后会自动转成近似值(如1996757981109010400),从而出现 ID 不一致的情况。
详细解释
-
JavaScript 安全整数限制 :JavaScript 中
Number类型的精度是 64 位双精度浮点数,能精确表示的最大整数是2^53 - 1(约 9e15),超过这个范围的整数会丢失精度,自动舍入成近似值。你这里的 ID1996757981109010434远大于9e15,所以前端接收后会变成1996757981109010400(末尾被舍入)。 -
其他地址 ID 没问题的原因 :其他地址 ID(如
3、4)是小整数,在2^53 - 1范围内,所以能被 JavaScript 精确表示。
解决方案
要解决大整数精度丢失问题,需要将后端返回的 ID 从数字类型改为字符串类型(字符串无精度限制),具体步骤如下:
1. 后端修改:返回 ID 为字符串
在后端的地址 VO 对象中,将id字段的类型改为String,并在返回时转为字符串:
java
运行
// 地址VO类(示例)
public class AddressVO {
// 原类型:Long → 修改为String
private String id;
private String receiver;
private String phone;
// ... 其他字段
// Getter/Setter方法:从数据库查询后,将Long类型的id转为String
public String getId() {
return id;
}
public void setId(Long id) {
this.id = id != null ? id.toString() : null;
}
}
2. 前端适配:接收字符串 ID(无需额外修改)
前端接收的 ID 会是字符串类型(如"1996757981109010434"),传递给删除 / 编辑接口时直接用字符串即可,后端会自动将字符串转为Long类型(框架会处理类型转换)。
验证效果
修改后:
- 后端查询到的 ID 是
1996757981109010434(Long 类型); - 后端返回的 VO 中
id是"1996757981109010434"(字符串类型); - 前端接收的 ID 是
"1996757981109010434"(无精度丢失); - 前端传递 ID 给后端时,后端会自动将字符串转为
Long类型,正常匹配数据库中的 ID。
总结
这个问题的本质是大整数跨语言传输的精度丢失,通过将 ID 转为字符串传输即可彻底解决,其他小 ID 不受影响。