后端返回的id到前端接收时,id改变了

案例:

核心原因

这个问题是 JavaScript 数字精度丢失导致的 ------ 后端返回的地址 ID(如1996757981109010434)是超过了 JavaScript 安全整数范围(2^53 - 1,即9007199254740991)的大整数,前端接收后会自动转成近似值(如1996757981109010400),从而出现 ID 不一致的情况。

详细解释

  1. JavaScript 安全整数限制 :JavaScript 中Number类型的精度是 64 位双精度浮点数,能精确表示的最大整数是2^53 - 1(约 9e15),超过这个范围的整数会丢失精度,自动舍入成近似值。你这里的 ID1996757981109010434远大于9e15,所以前端接收后会变成1996757981109010400(末尾被舍入)。

  2. 其他地址 ID 没问题的原因 :其他地址 ID(如34)是小整数,在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 不受影响。

相关推荐
梦想很大很大5 分钟前
使用 Go + Gin + Fx 构建工程化后端服务模板(gin-app 实践)
前端·后端·go
We་ct7 分钟前
LeetCode 56. 合并区间:区间重叠问题的核心解法与代码解析
前端·算法·leetcode·typescript
张3蜂14 分钟前
深入理解 Python 的 frozenset:为什么要有“不可变集合”?
前端·python·spring
无小道15 分钟前
Qt——事件简单介绍
开发语言·前端·qt
广州华水科技17 分钟前
GNSS与单北斗变形监测技术的应用现状分析与未来发展方向
前端
code_YuJun39 分钟前
corepack 作用
前端
千寻girling40 分钟前
Koa.js 教程 | 一份不可多得的 Node.js 的 Web 框架 Koa.js 教程
前端·后端·面试
全栈前端老曹41 分钟前
【MongoDB】Node.js 集成 —— Mongoose ORM、Schema 设计、Model 操作
前端·javascript·数据库·mongodb·node.js·nosql·全栈
code_YuJun42 分钟前
pnpm-workspace.yaml
前端
天才熊猫君1 小时前
“破案”笔记:iframe动态加载内容后,打印功能为何失灵?
前端