使用 MyBatis-Plus 用户登录异常

数据库有对应的用户但是查询 DB 却无法正常查询出来

1、首先排查逻辑删除

2、其次通过 MyBatis-Plus 输出执行 SQL 然后在 console 执行看是否有数据

3、注册是否使用注册接口进行注册,因为存储到 DB 里面的都是加密后的用户密码

image.png

排查是否逻辑删除

1、首先确保逻辑删除相关的配置

▼
yml
复制代码
mybatis-plus: global-config: db-config: logic-delete-field: isDelete # 全局逻辑删除的实体字段名 logic-delete-value: 1 # 逻辑已删除值(默认为 1) logic-not-delete-value: 0 # 逻辑未删除值(默认为 0)

2、对应的字段是否有 @TableLogic

▼
java
复制代码
/** * 是否删除 */ @TableLogic private Integer isDelete;

3、查看数据库里面的数据 isDelete 字段是否有数据 和 是否是 0 (配置文件的 logic-not-delete-value)

image-20250322095802663

输出日志执行 SQL

1、添加 MyBatis-Plus 日志

▼
yml
复制代码
mybatis-plus: configuration: # 仅在开发环境打印日志 log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

2、日志

▼
text
复制代码
Creating a new SqlSession SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@8824ddb] was not registered for synchronization because synchronization is not active JDBC Connection [HikariProxyConnection@213764115 wrapping com.mysql.cj.jdbc.ConnectionImpl@2d160394] will not be managed by Spring ==> Preparing: SELECT id,username,userAccount,avatarUrl,gender,userPassword,phone,email,userStatus,createTime,updateTime,isDelete,userRole,planetCode FROM user WHERE isDelete=0 AND (userAccount = ? AND userPassword = ?) ==> Parameters: leikooo(String), 7a364d20730ddeeea1a78b6b6c680c72(String) <== Total: 0 Closing non transactional SqlSession [org.apache.ibatis.session.defaults.DefaultSqlSession@8824ddb]
image-20250322101509441

3、把执行的 SQL 在 DB 的

把对应的 ? 替换成 parameters 的参数

▼
java
复制代码
SELECT id,username,userAccount,avatarUrl,gender,userPassword,phone,email,userStatus,createTime,updateTime,isDelete,userRole,planetCode FROM user WHERE isDelete=0 AND (userAccount = ? AND userPassword = ?)
image-20250322102653633

最终效果

▼
text
复制代码
SELECT id,username,userAccount,avatarUrl,gender,userPassword,phone,email,userStatus,createTime,updateTime,isDelete,userRole,planetCode FROM user WHERE isDelete=0 AND (userAccount = 'leikooo' AND userPassword = '7a364d20730ddeeea1a78b6b6c680c72')

4、执行 SQL

image-20250322103128346

执行 SQL

image-20250322103337351

查看 DB 数据

1、首先确认一下是否是用户名或者密码错误为了确保不是这个问题,重新注册一个账号 然后尝试登录一下

2、如果还是不行,就检查一下 逻辑删除

3、还是不行??应该有点离谱了,如果有报错信息就分析一下其他报错信息

0个评论
点击登录,快来和大家讨论吧~
表情
图片
暂无评论
leikooo
作者分享
ARTS 1101: 最长回文串与子序列匹配、一次 URL 请求的来回之旅与如何验证 AI 的交付
2
IP 数据库体积缩小 31%,关键竟然是合并重复子树
3
提到用 Rust 重写项目,很多人的第一反应往往是性能提升。以 Bun 为例,它最初主要采用 Zig 开发,后来在 2026 年发布的 v1.4 版本中将核心代码迁移到了 Rust。用 Rust 重写,性能、安全性往往是大家想要的,但是有没有想过用 Rust 重写还能发现 bug 呢? pgrust 这个项就是,他用 Rust 重新实现 PostgreSQL,保持通信协议和 SQL 方言兼容。为了确认新系统的行为和原版一致,开发者需要对着 PostgreSQL 的实际返回逐个比对。结果查着查着,有些异常不是新代码的锅,PostgreSQL 自己就是这样的。pgrust 开发者 Michael Malis 把其中几个报告给了 PostgreSQL 社区。 大概的问题: 1)SP-GiST 空间索引里有个函数判断点的方位,代码认为上、下、同一水平线三种情况已经穷尽了,末尾放了句「impossible case」兜底。结果在特定浮点边界附近,三种判断同时不成立,程序真走进了这个「不可能」的分支 2)日期格式缓存复用时,一个解析模式的标记没重置,导致同一条 JSONPath 查询在同一个会话里,换个执行顺序结果就不一样。 3)pgcrypto 的 crypt() 在某些输入下截断了多字节字符,返回的文本编码不合法。能存进去,但 pg_dump 导出时就炸了。 一个用 Rust 重写的新项目,测着测着,把运行了几十年的 PostgreSQL 里埋着的东西翻了出来。Rust 重写的价值,不一定只在跑得更快、更安全这一件事上。为了做到真正的兼容,开发者得把前人没怎么碰过的边界全走一遍,这个过程本身就在帮原版排雷。
4
ARTS 1025: 唯一字符与同构字符串、省词可能增加阅读负担与重新估算软件的实现成本
5
🎉 1024 程序员节快乐! 祝编程导航里的每一位程序员:offer 多多,薪资翻倍,面试顺利,早日拿下心仪 offer!💻
17
下载 APP