关于Mybatis-Plus的insertOrUpdate()方法使用时的问题与解决—数值精度转化问题

1 问题描述

今天在使用Mybatis-Plus的insertOrUpdate()方法时,新增能成功,编辑无法成功,报错如下:

我很好奇,明明我前端执行的是编辑逻辑,并不需要phone_number字段,而insertOrUpdate()方法为什么会执行INSERT语句?

而这里的phone_number报错也很好理解,就是因为数据库我设置了该字段NOT NULL,而编辑操作误执行为插入操作,因此并没有设置phone_number字段的值,于是就报错。因此现在问题就是研究为什么insertOrUpdate()方法没有正常执行UPDATE语句。

2 问题解决

2.1 问题排查分析

2.1.1 问题排查

首先,我数据库使用雪花算法生成主键id。

在打断点调试程序后发现,前端传来的id是1974004895060627500:

再前往浏览器的localstorage查看存储在前端的用户id也是1974004895060627500:

而数据库的主键id为1974004895060627458,可以发现,后三位不一样:

之所以查看id的问题,是因为insertOrUpdate()方法根据是否有id来判断当前是新增还是编辑数据,如果有id,则说明是编辑(先根据id能查到才能修改);如果没有id,则说明是新增。

现在,问题大概就清晰了,可能是因为后端返回给前端正确的id,但是不知道为什么前端存储了错误的id,导致前端使用错误的id编辑用户,查不到正确的用户,因此insertOrUpdate()就判断此次是新增用户,从而使用insert语句,而insert语句中phone_number是必传字段,不能为空,因此抛出异常。

那么为什么id从后端传到前端会发生后三位的错误情况?

2.1.2 底层逻辑

从过查询资料和AI,得到结论:

雪花算法生成的Long类型主键ID(如1974004895060627458),在数据库用bigint存储,这类ID是19位超大整数。

而前端的JavaScript 环境,其数字类型基于 IEEE 754 双精度浮点数标准,安全整数范围(53位)是 ±2^53 - 1(即 ±9,007,199,254,740,991),约等于 16 位十进制数。

当后端的主键ID超过这个范围时,JavaScript 会自动进行舍入或截断,导致 ID 值在前端存储和回传时发生改变

因此,后三位被四舍五入为500了,导致前端存储的主键id是错误的。

2.2 解决方案

在后端接收请求的DTO类型或后端返回响应的VO类型的属性ID添加String的序列化注解:

java 复制代码
@JsonSerialize(using = ToStringSerializer.class)

该注解会将Long类型的属性序列化为JSON字符串时直接转化为String字符串,从而保证主键ID保证完整的精度,前端接收到的响应也是String类型的主键ID,从而避免了数值类型转化的精度问题。

相关推荐
YOU OU5 小时前
Redis基础常识与命令
数据库·redis·缓存
腻害兔5 小时前
【若依项目-产品经理视角】深度拆解 RuoYi-Vue-Pro 商城模块:从商品管理到交易引擎,50 张表撑起一整套电商系统
java·大数据·vue.js·产品经理·ai编程
不好听6135 小时前
从一行 JSX 到屏幕像素:前端开发者必须懂的浏览器渲染管线
前端
恒拓高科WorkPlus5 小时前
企业级内网即时通讯建设模型:BeeWorks内网IM四层架构
前端
码智社6 小时前
AES加密原理详解及Java实现加解密实战
java·开发语言
前端小李子6 小时前
前端环境变量裸奔?我用 EnvShield 给它穿了件防弹衣
前端
youtootech6 小时前
HarmonyOS《柚兔学伴》项目实战25-我的页面、Web 嵌入与项目总结
前端·华为·harmonyos
小林ixn7 小时前
从零到一理解 React 父子组件通信:手写一个 Todo 应用带你彻底搞懂单向数据流
前端·javascript·react.js
萧瑟余晖7 小时前
JDK 26 新特性详解
java·开发语言
Database_Cool_7 小时前
OLTP 和 OLAP 区别详解:分析型数据库和事务型数据库怎么选(附阿里云 AnalyticDB MySQL 选型指南)
数据库·mysql·阿里云