什么是 MyBatis-Plus?它有什么作用?它和 MyBatis 有哪些区别?
- 标签:后端、Mybatis-plus、编程导航
🏛 业务架构师
MyBatis-Plus 是 MyBatis 的增强层:只做增强不做改变——底层仍是 MyBatis,SQL 映射能力原样保留,在此之上补齐"单表 CRUD 的自动化"。
核心能力按它省掉的工作讲:
- 通用 CRUD:继承 BaseMapper 即获得 insert/delete/update/select 全家桶,单表操作零 XML、零注解 SQL——把 70% 的体力活工具化,研发资源转投业务逻辑;
- 条件构造器:LambdaQueryWrapper 类型安全地拼动态条件,代替手写字符串拼接的动态 SQL(
eq(User::getStatus, 1).orderByDesc(User::getCreatedAt))——编译期检查字段,重构改名不炸; - 代码生成器:按表生成 entity/mapper/service 骨架,新模块起步从天到小时;
- 业务插件:分页、乐观锁(@Version)、逻辑删除(@TableLogic)、自动填充(创建人/时间审计字段)——审计合规字段在基础设施层自动写入,不靠开发自觉。
和 MyBatis 的关系一句话:MyBatis 管"SQL 怎么写",MyBatis-Plus 管"不用写的那部分"。
我的使用边界(防滥用):
- 单表简单操作用 MP,复杂查询回归手写 SQL——join 三张表以上的查询用 wrapper 硬拼,可读性崩塌还容易生成低效 SQL,别让"少写代码"绑架"SQL 可控";
- wrapper 动态条件要防"条件全空的全表查询"(加恒真兜底如 status 限定);
- 团队规范里明确"分页插件统一配置、逻辑删除统一字段",避免各服务各玩各的。
定位总结:MyBatis-Plus 是效率放大器——它不改变架构,但把团队从 CRUD 泥潭里捞出来。工具的 ROI = 省下的时间是否流向了更有价值的业务设计。
🏗 系统架构师
MyBatis-Plus 是 MyBatis 的增强工具(官方口号:只做增强不做改变)——底层仍是 MyBatis,开箱即用地补齐了单表 CRUD 的效率短板。
核心能力:
- 通用 CRUD:继承 BaseMapper 即获得 insert/delete/update/select 全套方法,不用写一行 XML;
- 条件构造器:LambdaQueryWrapper 类型安全的动态条件(
eq(User::getName, x).gt(User::getAge, 18)),编译期检查字段,重构安全; - Service 层封装:ServiceImpl/IService 提供批量、链式查询;
- 代码生成器、分页插件(PaginationInnerInterceptor)、乐观锁插件、逻辑删除、自动填充(create_time)、多租户插件——常用企业级横切能力全家桶。
与 MyBatis 的区别与关系:MP 不替换 MyBatis,复杂 SQL 照旧手写 XML,两者混用——单表走 MP、多表 join 走 XML 是我团队的规范分工。
架构评价:它解决的是国内互联网"80% 单表 CRUD 重复劳动"的效率问题,同时保留 SQL 可控性,比全自动化 ORM(JPA)更符合"SQL 权留给工程师"的团队偏好。风险点在滥用 Wrapper 写复杂查询导致 SQL 散落 Java 代码,我会划清边界:复杂逻辑必须沉淀到 XML 统一评审。
💻 全栈开发专家
MyBatis-Plus = MyBatis 的增强层:只做增强不做改变——引入后 MyBatis 的 XML、注解用法全部保留,额外白送单表 CRUD、条件构造器、分页、代码生成。
核心能力对应代码:
java
// 1. 单表 CRUD:继承 BaseMapper,零 XML
public interface UserMapper extends BaseMapper<User> {}
// 2. 条件构造器:类型安全的动态 SQL
List<User> list = userService.lambdaQuery()
.eq(User::getStatus, 1)
.likeRight(User::getName, "张")
.gt(User::getAge, 18)
.orderByDesc(User::getCreateTime)
.last("limit 10")
.list();
// 3. 分页:一个拦截器
PaginationInnerInterceptor p = new PaginationInnerInterceptor(DbType.MYSQL);和 MyBatis 的关系:依赖里仍包含完整 MyBatis,复杂多表查询照样写 XML——MP 解决的是"单表操作占 70% 的体力活"。
我项目里的高频特性:
@TableLogic逻辑删除、@Version乐观锁、autoFillHandler自动填充 create_time/update_time;- 多租户插件
TenantLineInnerInterceptor,SQL 自动拼租户条件; - 代码生成器(新表一键出 entity/mapper/service)。
踩坑:last() 拼接要防注入(别拼用户输入);分页插件必须注册否则分页失效返回全量;复杂统计别硬用 Wrapper,该写 XML 就写 XML——MP 是提效工具不是教条。