后端返回的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 不受影响。

相关推荐
程序员黑豆2 小时前
Java类型推断完全指南:从var到菱形运算符,掌握使用限制与最佳实践
java·前端·ai编程
To_OC3 小时前
踩了个 TS 的坑之后,我终于把 type 和 interface 掰明白了
前端·react.js·typescript
GreenTea3 小时前
深度解读 Anthropic 多智能体报告:更强的模型 ≠ 更好的协调
前端·后端·算法
浮生望3 小时前
前端API工程化:用 Mock 数据与 Axios 配置实现独立于后端的并行开发
前端
万少4 小时前
给 DeepSeek Harness 装个"应用商店":一条命令,595 个插件随你逛
前端·javascript·后端
波波0074 小时前
C# 15 重磅新特性: 带标签 break 与 continue:重新定义嵌套循环控制流
服务器·前端·c#
云和数据.ChenGuang4 小时前
fastapi的参数剖析
人工智能·深度学习·机器学习·语言模型·状态模式·fastapi
Brown.alexis5 小时前
es6知识点1-自备使用
前端·ecmascript·es6
小爬的老粉丝6 小时前
JavaScript 纯前端预览 WPS:先识别容器,再路由解析器
前端·javascript·wps
计算机魔术师6 小时前
新兴多智能体系统的模式与问题
前端