1. 面试官问MyBatis-Plus，到底在问什么
先聊点实际的。MyBatis-Plus这个名字，在Java后端面试里出现的频率，这几年是真的高。我身边不少同学去面中小厂和部分大厂，几乎都会在项目环节被问到"你项目里用的ORM是什么""分页怎么做的""逻辑删除怎么实现的"。十个人里有八个回答MyBatis-Plus，但能把这八个字背后的细节讲清楚的，可能不到两个。
这其实暴露了一个问题：很多人把MyBatis-Plus当成"MyBatis的增强工具"，觉得BaseMapper里那几个方法够用就行。但面试官问MyBatis-Plus，不是想听你说"它很好用"，而是想通过这个问题判断三件事：
- 你是真的会在项目里用，还是背了几个注解就上考场；
- 你对ORM框架的理解停留在API调用层，还是能深入到执行原理；
- 遇到复杂业务的时候，你是无脑上插件，还是能清楚地知道它的边界在哪里。
这篇文章，我打算换一个角度来聊。既然标题是面试题，那我就从"面试官视角"出发，把所有高频考点拆成四块：核心原理、高频注解、插件机制、实战陷阱。每道题我会先给出标准回答思路，再补充一些你在真实项目里才会踩到的细节，以及我自己在面试中会追问的点。
说个题外话，我一直觉得MyBatis-Plus的定位很有意思。它不是要取代MyBatis，而是把MyBatis开发中最啰嗦的那部分——CRUD、分页、条件构造——做了极致封装。但正因为"封装得太好"，反而让很多人忽略了它底下的SQL生成逻辑。面试题的价值，恰恰就是把这块"被忽略的地基"挖出来看。
下面我们直接进正题。我会按面试中由浅入深的逻辑来组织：先从最基础的"它和MyBatis的关系"讲起，再深入到各个关键机制的实现原理，最后用真实项目里的坑做收尾。全程不背八股文，全是能落地的东西。
2. 它跟MyBatis到底什么关系？——最容易被追问的第一题
2.1 别只说"增强"两个字，面试官想听的是细节
"请介绍一下MyBatis-Plus和MyBatis的区别。"这是几乎必问的开场题。很多人第一反应就是"MyBatis-Plus是MyBatis的增强版，简化开发"。这句话没错，但太泛了，等于没说。
我建议你按下面三个维度去组织回答，既能让面试官觉得你有深度，又不会跑偏：
- 从定位上看：MyBatis是一个半自动ORM框架，SQL仍然由开发者编写，只是把结果映射、参数绑定这些重复劳动交给了框架；MyBatis-Plus则是在不改变MyBatis底层机制的前提下，帮你把"通用CRUD"这部分直接生成了。注意，它没有接管SQL，它只是替你写了那些没营养的SQL。
- 从核心特性上看：MyBatis-Plus提供了通用Mapper（
BaseMapper）、条件构造器（Wrapper）、分页插件、逻辑删除、自动填充、乐观锁等能力，这些在原生MyBatis里都需要你手动去写XML或者注解SQL。 - 从侵入性上看：MyBatis-Plus是"吸入式"的，你完全可以把原来的MyBatis项目逐步改造过来，先加依赖，再让Mapper继承
BaseMapper，原有XML文件可以继续用。
讲到这儿，面试官往往会顺势问一句："那MyBatis-Plus是替换掉了MyBatis吗？"答案是否定的。它运行在MyBatis之上，底层走的还是MyBatis的SqlSessionFactory、Executor那套生命周期。你可以这么理解：MyBatis是发动机，MyBatis-Plus只是一套自动换挡系统，燃油燃烧的原理没变。
2.2 从一次insert看MyBatis-Plus的SQL生成逻辑
这个点是我面试别人时最常用的"试金石"。我问："BaseMapper.insert(entity)，它到底是怎么把一条Java对象变成SQL的？"
很多人回答不上来，因为平时用得太顺手了。实际上，BaseMapper接口里定义的方法，是在MyBatis-Plus的AbstractMethod体系中被逐个注册成MappedStatement的。流程大概是这样：
- 项目启动时，MyBatis-Plus的
MybatisMapperRegistry接管了MyBatis的Mapper注册过程； - 它扫描所有继承
BaseMapper的Mapper接口，针对接口里的泛型实体类，生成一套预定义好的SQL模板（比如insert、selectById、deleteById）； - 这些SQL模板以
MappedStatement的形式注册进MyBatis的配置中； - 真正执行时，MyBatis-Plus再把实体对象的值填充进SQL模板，交给MyBatis执行器。
这里有一个面试加分点：你不是不能改写这些内置方法的SQL行为。MyBatis-Plus预留了@InterceptorIgnore、自定义Method等扩展点，一些公司甚至会在框架层面重写insert方法，注入"自动填充审计字段"之类的逻辑。面试时如果能聊到这一层，说明你是真的读过源码，而不是停留在API手册。
2.3 面试现场的反问预判
面试官听完你的回答，十有八九会追问一句："那为什么不直接用MyBatis Generator或者通用Mapper这种方案？"
这个追问其实是在考察"你有没有真正做过技术选型对比"。你可以这样答：
- MyBatis Generator是生成代码，生成完就是一堆静态XML，以后改表结构要重新生成或者手改XML；
- MyBatis-Plus是"运行时动态生成SQL"，不需要为每张表维护一套CRUD XML，表结构变更后，Java实体改一下就行，不用动XML；
- 通用Mapper（比如tk.mybatis）在某些场景也不错，但MyBatis-Plus在条件构造器、分页插件、多租户插件这些扩展上更成体系。
这样回答完，基本就能把这道题拿稳了。不需要背源码行数，但逻辑链条必须清晰。
3. 条件构造器Wrapper：面试里出现频率最高的"技术暗号"
3.1 LambdaQueryWrapper和QueryWrapper的选型逻辑
如果你履历里写了"熟练使用MyBatis-Plus"，那Wrapper相关的题基本躲不掉。最常见的一道就是："LambdaQueryWrapper和QueryWrapper有什么区别？你平时怎么选？"
标准回答要点如下：
QueryWrapper直接用实体字段的字符串列名，比如.eq("user_name", "zhangsan")。缺点是字段名被硬编码，数据库改列名或Java属性改名后，编译期根本发现不了，只有运行时SQL报错才知道。LambdaQueryWrapper用方法引用，比如.eq(User::getUserName, "zhangsan")。好处有两个：一是类型安全，字段名拼错会在编译期直接报错；二是有重构友好的特性，用IDE重命名实体属性时，SQL条件会自动跟着变。- 实际项目里我基本只推荐
LambdaQueryWrapper。除非是动态拼接特别复杂的报表SQL，需要逻辑分组、嵌套条件等场景，QueryWrapper的字符串写法反而更直观时，才会用旧的。
这里有一个容易暴露功底的追问："LambdaQueryWrapper是怎么从方法引用拿到字段名的？"
答案是借助SerializedLambda。Java 8的序列化Lambda在运行时可以拿到实现方法的implMethodName，MyBatis-Plus通过解析这个信息，把它还原成数据库列名。比如User::getUserName经过SerializedLambda取出的方法名是getUserName，再按驼峰转下划线规则变成user_name。这个过程发生在条件构造器构建SQL的瞬间，所以能保证写Lambda的那一刻拿到的就是当前最新的属性名。
3.2 嵌套条件的括号问题：面试最刁钻的一集
"查出所有姓张并且（年龄大于30或者工资小于5000）的人"，这个需求用Wrapper怎么写？
这是我在面试中最常用的实操题。很多人会跟着感觉写：
List<User> users = userMapper.selectList( new LambdaQueryWrapper<User>() .like(User::getName, "张") .gt(User::getAge, 30) .lt(User::getSalary, 5000) );这段代码虽然能跑，但它的语义完全错了。没有括号控制时，三个条件默认是用AND连接的，等价于"姓张 且 年龄大于30 且 工资小于5000"。想实现题目里的"或"逻辑，必须用and开一个嵌套条件：
List<User> users = userMapper.selectList( new LambdaQueryWrapper<User>() .like(User::getName, "张") .and(wrapper -> wrapper .gt(User::getAge, 30) .or() .lt(User::getSalary, 5000)) );and(wrapper -> ...)方法传入一个Consumer，里面条件整体被包裹进一个括号并跟前面的条件做AND，括号内部再用.or()控制两个子条件的OR关系。
面试时如果能顺手写出这段代码，再解释一句"Wrapper内部是用AND和OR组合成一棵条件树，嵌套条件通过分段拼接父子节点实现"，基本上这道题就是满分水平。
顺带提醒一下：.and()和.or()这两个方法，别名分别是and(Consumer)和or(Consumer)。如果直接在链式调用里写.or().eq(...).or().eq(...)，很容易产生混乱的SQL，这是很多入门同学的翻车现场。
3.3 apply方法：最后那5%的场景
除了常规方法，MyBatis-Plus还提供了.apply()，允许你在Wrapper里直接拼接原生SQL片段。比如需要用到DATE_FORMAT、JSON_EXTRACT这类数据库函数时，Wrapper的常规方法表达不了：
userMapper.selectList( new LambdaQueryWrapper<User>() .apply("DATE_FORMAT(create_time, '%Y-%m-%d') = {0}", "2024-01-01") );注意两点：
{0}是占位符，代表后续传入的参数，这样可以避免SQL注入风险。千万别直接字符串拼接用户输入，这是我在Code Review里最常抓的问题。.apply()是最后的手段，能用.ge()、.le()等API表达的，不要为炫技去拼原生SQL。
面试回答到apply时，可以加一句：apply其实对应了QueryWrapper内部一个SqlSegment类型，它的优先级在条件树里等同于普通字段条件。个人经验是，一次查询中apply的使用频率越低，代码越健康，这是我为什么把它放在最后讲的原因。
4. 分页插件与物理分页：必考题里的底层原理
4.1 分页是"逻辑分页"还是"物理分页"？——经典送命题
MyBatis-Plus的分页面试题，大概率从一句灵魂拷问开始："你项目里的分页是内存分页还是数据库分页？"
在MyBatis-Plus里，如果你只调selectPage而不配置分页插件，默认走的是内存分页——所有数据先查出来再在Java内存里截取，这是很多人根本没意识到的坑。而配置了PaginationInnerInterceptor之后，它会改写成数据库分页，比如MySQL生成LIMIT ?，PostgreSQL生成LIMIT ? OFFSET ?。
面试里被问到原理时，可以分三层回答：
- 分页插件实现了MyBatis的
Interceptor接口，属于Executor层面的拦截器； - 当它检测到
MappedStatement里存在IPage类型的参数时，会先拦截下来，改写原始SQL，生成一个带COUNT的统计SQL用于查总数，再生成一个真正执行查询的分页SQL； - 改写完SQL后，还会把分页结果封装成
Page<T>对象，包含当前页数、总条数、总页数等数据。
这里面值得多说一句的是：分页插件改写SQL，改的是BoundSql里的sql属性。它内部通过JsParser解析SQL语法树，再在原语句外层包一层分页语法。这也是为什么，如果你在Mapper方法里写了特别复杂的SQL（比如含UNION、FOR UPDATE），分页插件有时会解析出错——但多数情况它能自动识别。
4.2 COUNT查询的性能陷阱与经验手法
面试官可能接着问："如果你的分页查询很慢，会怎么排查？"
我建议从这三点入手：
- 第一看COUNT。MyBatis-Plus默认会把原查询包成
SELECT COUNT(*) FROM (原SQL)，如果原SQL里含多张表JOIN，COUNT就会非常重。我通常会在不重要的列表查询里重写一个更轻量的COUNT查询，或者干脆用Page构造时指定searchCount=false。 - 第二看深分页。MySQL里
LIMIT 100000, 20虽然能返回数据，但前10万行是白扫的。更合理的方式是"延迟关联"或"游标分页"。MyBatis-Plus的分页插件支持自定义IDialect，在需要极致优化时，可以针对特定SQL做改写。 - 第三看索引。分页排序字段如果没走索引，深分页问题会成倍放大。
我有个习惯：新接手一个项目时，一定会把列表页所有分页SQL打开慢查询日志跑一遍。很多性能问题不是MyBatis-Plus造成的，而是开发者把它的LIMIT当成了万能药。
4.3 面试实战：手写一个分页拦截器
真正的高手面，可能会要求你"把分页插件的核心逻辑讲一讲"。这里我给一个简化的思路，不需要背全部源码，但你要能画出关键流程：
- 拦截
Executor.query方法； - 判断方法入参中是否包含
IPage参数； - 如果包含，先调用
count方法获得总数，并把它写入IPage对象； - 用
Page的offset和size改写原SQL为分页SQL； - 执行改写后的SQL，将返回的
List和总数一起封装进Page。
把上面五步用自己话说清楚，面试官基本就满意了。如果还能补充一句"分页插件不像逻辑删除那样是SQL片段级改写，它是Executor层整体拦截"，这就直接说明你理解MyBatis拦截器的位置在哪，比单纯背插件名高下立判。
5. 逻辑删除与自动填充：实体层的三个高频追问
5.1 逻辑删除的"假删除"到底是怎么实现的
先说结论：逻辑删除不是MySQL的功能，是MyBatis-Plus在SQL生成时自动帮你追加一个条件。配置了@TableLogic之后，selectList产生的SQL会自动带上WHERE deleted = 0（或你指定的值），deleteById产生的SQL则会变成UPDATE table SET deleted = 1 WHERE id = ?。
面试官如果追问"它是在哪个环节加的条件"，你要能答出"SQL注入阶段"。MyBatis-Plus在生成MappedStatement时，会通过TableInfo里的逻辑删除字段信息，把所有内置SQL模板里的对应位置注入条件。如果你用的是XML里手写的SQL，逻辑删除是不会自动生效的——这是很多开发者的认知盲区。
我举个例子，你有个自定义XML：
<select id="selectAll" resultType="User"> SELECT * FROM user </select>此时MyBatis-Plus的内置逻辑删除拦截器不会帮你自动加WHERE deleted=0。除非你使用@InterceptorIgnore或在XML里手动拼接，否则这条SQL会把已删除的数据一起查出来。
所以我的建议是：能用BaseMapper内置方法就用内置方法；自定义XML时必须主动处理逻辑删除字段。面试时能提到这一层，等于告诉面试官"我不光知道注解，我还知道注解的边界"。
5.2 自动填充：谁在维护create_time和update_time
"你的表里有create_time和update_time，谁来处理这两个字段？"这题也是高概率出现。
标准答案是：在实体字段上加上@TableField(fill = FieldFill.INSERT)和@TableField(fill = FieldFill.INSERT_UPDATE)，然后实现一个MetaObjectHandler：
@Component public class MyMetaObjectHandler implements MetaObjectHandler { @Override public void insertFill(MetaObject metaObject) { this.strictInsertFill(metaObject, "createTime", LocalDateTime.class, LocalDateTime.now()); this.strictInsertFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } @Override public void updateFill(MetaObject metaObject) { this.strictUpdateFill(metaObject, "updateTime", LocalDateTime.class, LocalDateTime.now()); } }注意strictInsertFill和strictUpdateFill这两个方法名里的"strict"——它的意思是：只有实体字段值为空时才填充。如果你手动设置了createTime，框架不会覆盖。这个细节如果不清楚，容易出现"我前端传了一个时间，怎么没生效"的困惑。
这里我补充一个真实项目的教训：自动填充只对MyBatis-Plus内置方法生效。如果你的Mapper里有个自定义updateSql，哪怕里面写了UPDATE user SET update_time = ...，或者你直接用SqlRunner执行原生SQL，MetaObjectHandler都不会触发。我第一次在这上面踩坑时，排查了半天，最后发现是同事在XML里覆盖了更新逻辑。
5.3 乐观锁：并发场景的必答模板
最后一个高频考点是乐观锁。配置逻辑是：
- 实体加
@Version注解； - 配置乐观锁插件
OptimisticLockerInnerInterceptor； - 更新时，MyBatis-Plus会自动把SQL改写成
UPDATE ... SET version = version + 1 WHERE id = ? AND version = ?，如果更新影响行数为0，说明数据已被其他人改过。
面试官可能反问："数据库不是有悲观锁吗？为什么还要乐观锁？"
可以这样回答：悲观锁（SELECT FOR UPDATE）适合写多读少、冲突激烈的场景，但会带来锁等待和吞吐量下降；乐观锁适合读多写少、并发冲突低的场景，每次更新时检测版本号，冲突就让用户重试，不用长时间持锁。实际项目里，下单、扣库存这类高并发读操作场景，玩的就是乐观锁这套思路。
有一个隐藏考点是：版本号不能为null。配置了@Version的字段，初始化时必须给值（比如0），否则乐观锁插件在生成SQL时如果拿到null，会导致WHERE version = null这样恒假的条件，更新永远失败。这也是很多"乐观锁不生效"问题的根源。
6. 代码生成器与自定义SQL：干活时的选择和取舍
6.1 代码生成器到底生成了哪些东西
讲到实战，不得不提MyBatis-Plus的代码生成器（AutoGenerator）。面试不会让你现场写整套生成器，但会问"它生成的东西你都会改哪些"。
我的经验是，生成器生成的实体类和Mapper骨架，只能当"初稿"。真正需要人工动的地方通常有三处：
- 实体的
@TableName和@TableField是否需要额外指定，比如字段名与属性名不一致时； - 是否要给实体字段补充
@TableLogic、@Version、@TableField(fill = ...)这些元信息； - 复杂查询的XML需要手写，分页查询和关联查询不可能靠
BaseMapper一个方法搞定。
有一些团队为了省事，让生成器把所有表都生成一遍，导致项目里出现几十个空转的Service，我其实不太赞同。生成器适用于"表结构已经稳定、字段映射简单"的场景，而业务模型还没建立起来时，机械化生成反而加剧维护成本。
6.2 自定义SQL和BaseMapper混用的正确姿势
MyBatis-Plus的BaseMapper解决不了所有查询，尤其是多表连接、子查询、动态排序这种场景。实际项目里，我们通常会让Mapper接口同时继承BaseMapper<T>和自己定义的接口方法，比如：
public interface UserMapper extends BaseMapper<User> { List<UserVO> selectUserWithOrders(@Param("userId") Long userId); }然后在XML里写这个selectUserWithOrders的SQL。两者共存完全没问题。关键是脑子里要有清晰的分界线：
- 单表简单CRUD：用
BaseMapper，享受逻辑删除、自动填充、乐观锁的红利； - 多表关联、复杂业务：手写XML，MyBatis-Plus不会干涉你XML里的SQL。
面试时能把这个边界说清楚，比背十道八股文都加分。因为这意味着你真的用这个框架做过项目，而不是只看过文档。
6.3 关于IService：很多人忽略的Service层封装
还会有一道题："BaseMapper和IService的关系是什么？为什么能用IService的saveOrUpdate?"
IService是MyBatis-Plus对Service层的一次能力下沉。ServiceImpl里封装了批量插入、批量更新、saveOrUpdate这些常用方法。这里我想特别点一下saveOrUpdate的语义：它并不是"存在就更新，不存在就插入"的万能方法。它判断的依据是主键有没有值、以及主键对应的记录存不存在。如果你传一个id在表里找不到，部分场景下它可能不会走插入逻辑，导致你以为它插入了，实际没有任何效果。
这是典型的"文档里一句话，代码里一天坑"。如果你项目中用到saveOrUpdate，一定要先确认底层逻辑是否符合预期。另外，ServiceImpl的saveBatch默认走的是一条条插入，只是在JDBC层面重用了连接，和真正的一条SQL插入多行还是有性能差距。数据量非常大时，建议自己写自定义批量插入。
7. 面试总结之外的实战告诫：这些坑，你可能也会踩
7.1 字段映射的"驼峰"陷阱
MyBatis-Plus默认开启驼峰转下划线映射，但你如果用了@TableField指定了列名，这个转换逻辑就会被覆盖。比如你写@TableField("user_name")，结果实体属性名叫userNmae（拼错了），SQL里就会引用不存在的列。这种错误编译期完全查不出来，只能靠运行时SQL报错。我的习惯是：实体字段和数据库列名在命名上保持高度一致，@TableField只在必要的时候才用。
7.2 分页插件和自定义拦截器的顺序问题
MyBatis的拦截器是有顺序的。如果项目里同时存在多个Interceptor，它们的执行顺序是由@Intercepts注解配置以及InterceptorChain中注册顺序决定的。分页插件如果排在别的拦截器后面，可能拿不到已经被修改的BoundSql，导致分页失效或者SQL错乱。
我遇到过一种场景：项目里有个加密拦截器，在Executor层先对参数解密，分页插件和它的顺序没配好，导致某个查询一直"分页不生效"。最后把拦截器顺序调整后，问题立刻消失。所以引第三方插件时，一定要清楚它在拦截器链中的位置。
7.3 多租户插件：面试加分项，但别随意用
MyBatis-Plus的多租户插件（TenantLineInnerInterceptor）会在SQL里自动追加租户ID条件，比如WHERE tenant_id = ?。这个功能听起来很强大，但它对SQL的改写逻辑非常复杂，像INSERT语句中忽略某些表、UPDATE语句中不能修改租户字段等场景都需要精细配置。
面试时如果提到多租户，不建议只背配置步骤，而应该强调"多租户是架构问题，不是简单的字段过滤问题"。比如租户ID的获取方式（登录态、请求头、线程上下文），数据隔离级别（共享表还是分库），这些都是设计层面的讨论。你主动把话题引到架构高度，面试观感会完全不一样。
7.4 从一次线上事故讲起：逻辑删除+唯一索引的致命冲突
这是我认为最有价值的一个经验分享，也是不少人踩过的大坑。
假设你的user表有一个唯一索引uk_user_name，字段是user_name。用户A改名时把user_name改成了"abc"，但业务上会先保留旧记录做逻辑删除，然后再插入一条新记录。此时旧记录的deleted标记为0，新记录也想插user_name = "abc"。但如果唯一索引没包含deleted字段，插入直接失败，业务中断。
正确的做法是：要么把唯一索引改成联合索引(user_name, deleted)，配合逻辑删除的字段值做区分；要么设计成物理删除+归档表。这个案例告诉我们：逻辑删除不是免费的，它在和数据库约束、唯一键一起工作时，需要额外的方案设计。
面试中如果你能主动举出这个案例，几乎就能让面试官认定你是有真实项目经验的人。
7.5 性能优化时的最后一招：看SQL
无论你是面试还是实际开发，遇到MyBatis-Plus的诡异问题，第一件事永远是打开SQL日志，看它到底生成了什么。MyBatis-Plus官方提供了mybatis-plus.configuration.log-impl配置，可以用StdOutImpl直接把SQL打到控制台。
mybatis-plus: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl看到SQL后，很多问题其实一目了然：条件少了吗？别名是错的吗？LIMIT是对的但排序没走索引？逻辑删除条件加了吗？这些都比盲猜快得多。我在排查问题时的第一步永远是先看生成的SQL，再看Java代码，最后才是翻文档。
最后说点题外话
这篇文章虽然以面试题为切入点，但核心目的并不是让你背题。MyBatis-Plus真正的难点，从来不是某个注解怎么写、某个方法怎么调，而是你愿不愿意在"用起来很方便"的外衣下，去看一眼它生成的SQL，想一想它为什么会这么设计。
我自己的体会是：用MyBatis-Plus的时间越长，越觉得"简化开发"这几个字的代价，是开发者对SQL的感知力在降低。所以每次写完一个复杂查询，我都会去翻一下完整SQL，养成这个习惯之后，线上问题会少很多。
如果你是正在准备面试的人，希望这篇文章能帮你把MyBatis-Plus从"会用的工具"变成"聊得清的框架"；如果你已经在用它做项目，也希望这里的几个实战细节，能成为你排查问题时的一个思路起点。最后留一个小技巧：面试官问"MyBatis-Plus还有什么你印象深刻的点"时，不妨谈谈@SqlParser和@InterceptorIgnore，这两个注解能让你精准控制某些Mapper方法不受租户插件和分页插件干扰。知道它们的人不多，但一聊出来，场面很容易就变成"你这块真的研究过"。
