登录
首页 >  文章 >  java教程

MyBatis-Plus查询与代码生成实战指南

时间:2026-05-07 16:11:42 172浏览 收藏

本文深入剖析了MyBatis-Plus在实际开发中最易踩坑的四大核心场景:BaseMapper查询为空的根源在于驼峰命名策略未开启或QueryWrapper误用数据库列名而非实体属性名;代码生成器生成的代码需手动配置Mapper扫描、校验字段类型映射与注解启用,否则会因Bean缺失或类型不匹配导致运行时异常;IService与BaseMapper并非简单替代关系,前者提供开箱即用的事务保障与服务编排能力,后者更轻量但需自行管理事务边界;而生成的Controller仅具基础骨架,缺乏参数校验、权限控制、分页适配和敏感字段防护等生产必备能力——真正落地的关键,恰恰藏在命名策略配置和事务意识这两个常被忽视的细节里。

Java实战如何利用MyBatis-Plus简化开发_BaseMapper基础查询与代码生成器使用

BaseMapper 的 selectList 为什么查不到数据?

不是 SQL 写错了,大概率是条件没生效或实体字段没对齐。MyBatis-Plus 的 BaseMapper 默认用属性名匹配数据库列名,不自动做驼峰转下划线——除非你显式开启。

  • 检查是否在 application.yml 中配置了 mybatis-plus.configuration.map-underscore-to-camel-case=true
  • QueryWrapper 构造时,传入的字段名必须是 Java 实体属性名,不是数据库列名;比如实体有 userName,就写 wrapper.eq("userName", "zhang"),别写 "user_name"
  • 空值字段不会被拼进 SQL,eq("status", null) 直接被忽略,要用 isNull("status")
  • 如果用了 @TableField(exist = false),它也不会参与查询,哪怕你在 wrapper 里写了这个字段名

代码生成器生成的 EntityMapper 怎么快速接入项目?

生成器本身不负责注册 Bean,也不自动扫描 Mapper 接口——这一步漏了,BaseMapper 方法调用会直接报 BeanCreationExceptionNo qualifying bean

  • 确保生成的 Mapper 接口继承了 BaseMapper,且接口上加了 @Mapper 注解,或者在启动类上用 @MapperScan("com.xxx.mapper") 扫描包路径
  • 生成的 Entity 类必须有无参构造函数(Lombok 的 @Data 默认提供,但若手动写了有参构造,得补上 @NoArgsConstructor
  • 数据库字段类型映射要核对:比如 MySQL 的 datetime 对应 Java 的 LocalDateTime,不是 Date;生成器默认按类型推断,但时区或精度不一致会导致查出来为 null
  • 生成器模板里若关闭了 enableTableFieldAnnotation,字段就不会带 @TableField,遇到列名和属性名不一致时会查不到数据

IServiceBaseMapper 到底该用哪个?

不是“更高级就更好”,而是看场景:简单单表 CRUD 用 BaseMapper 更轻量;需要事务控制、批量逻辑、前后置钩子,就绕不开 IService

  • BaseMapper 是接口,方法都是单条 SQL 映射,不带事务——你自己调 insert() 后再抛异常,数据已经写进去了
  • IService 默认实现类 ServiceImplBaseMapper 包了一层,所有方法都加了 @Transactional(默认传播行为 REQUIRED),适合服务层编排
  • 自定义 service 方法想复用 BaseMapper,别直接 new Mapper 实现类,而是通过构造注入或 @Autowired 拿到 mapper 实例
  • 如果用了 saveBatch 这类批量方法,注意 MySQL 的 rewriteBatchedStatements=true 参数没配的话,性能可能比循环插入还差

生成器输出的 Controller 能不能直接用?

能跑,但上线前几乎都要删——它只解决“能动”,不解决“该怎么动”。特别是参数校验、权限、分页封装、异常统一处理这些,生成器一概不管。

  • 生成的 save 方法直接接收 Entity,没做参数校验,前端传个超长字符串或非法枚举值,后端就直接插库失败
  • 分页用的是 Page 对象,但前端传参格式(如 current=1&size=10)需要配合 PageHandler 或自定义 Resolver,否则 Pagerecords 为空
  • 生成的 removeById 不校验用户是否有权限删这条数据,也不记录操作日志,线上出问题没法追溯
  • 如果实体里有敏感字段(如密码),生成的 update 方法会把整个对象全量更新,可能误清空非空字段
实际用下来,最常被忽略的是字段命名策略和事务边界——一个导致查不到数据,一个导致数据不一致。这两处不盯紧,后面加再多日志和监控都补不回源头问题。

终于介绍完啦!小伙伴们,这篇关于《MyBatis-Plus查询与代码生成实战指南》的介绍应该让你收获多多了吧!欢迎大家收藏或分享给更多需要学习的朋友吧~golang学习网公众号也会发布文章相关知识,快来关注吧!

资料下载
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>