MyBatis-Plus lambda cache 报错与 Mockito 单测

改一个 Service 的分支逻辑，顺手补个纯 Mockito 单测，结果测试还没跑到断言就红了：can not find lambda cache for this entity [com.xxx.order.entity.Order]。第一反应是"缓存没清"，于是清缓存、重启 IDE、mvn clean，全套动作做了一遍，问题纹丝不动。后来把堆栈从头读到尾才发现，这个异常从字面上就在误导人——它压根不是缓存失效，而是根本没人往缓存里写过东西。MyBatis-Plus 的 lambda 列名解析依赖一张启动期注册的静态映射表，这张表由 Mapper 扫描过程填充；而纯 Mockito 单测里 Mapper 是动态代理假对象，扫描链路整条被绕开了，表是空的，于是包装器一构造就炸。这篇就把这条链路从头拆一遍：异常到底在哪一行抛出、lambda cache 是谁在什么时候写进去的、Mock 之后断在哪一环、三种修法各自适合什么场景，以及我在真机上踩过的那几个坑。如果你也卡在 MyBatisPlus 的 lambda 包装器和单元测试之间，尤其是团队里同时在推 Mockito 单测和 MyBatis-Plus 重构的，这篇应该能直接省你半天。

1. 报错现场还原：为什么单测里 Wrapper 一构造就炸

1.1 一段最小复现代码

先给一个能百分之百复现的最小样例，实体、Service、测试三件套。实体用最常见的驼峰字段加下划线表名：

@Data @TableName("t_order") public class Order { @TableId(type = IdType.AUTO) private Long id; private String orderNo; private Integer status; private LocalDateTime createTime; }

Service 里用 lambda 包装器拼条件，这也是现在绝大多数项目的标准写法：

@Service @RequiredArgsConstructor public class OrderService { private final OrderMapper orderMapper; public List<Order> listPaid(String orderNo) { LambdaQueryWrapper<Order> wrapper = Wrappers.<Order>lambdaQuery() .eq(Order::getOrderNo, orderNo) .eq(Order::getStatus, 1); return orderMapper.selectList(wrapper); } }

测试就是一个干净的 Mockito 单测，不启 Spring，不连库，不加载任何 XML：

@ExtendWith(MockitoExtension.class) class OrderServiceTest { @Mock private OrderMapper orderMapper; @InjectMocks private OrderService orderService; @Test void listPaid_shouldFilterByStatus() { when(orderMapper.selectList(any())).thenReturn(Collections.emptyList()); orderService.listPaid("NO-20240101"); } }

跑起来的结果是：when(...)打桩正常，orderService.listPaid(...)一进去就抛异常。注意一个关键细节——异常不是在selectList里抛的，而是在拼包装器的那一行抛的。也就是说，代码连 Mapper 都没碰到就挂了。这一点非常容易被忽略，很多人在 Mapper 上找半天，方向从一开始就错了。

1.2 那一长串堆栈里真正值得看的三行

把堆栈往下翻，会发现真正有信息量的就三行调用：

at com.baomidou.mybatisplus.core.toolkit.LambdaUtils.getColumnMap(LambdaUtils.java:xxx) at com.baomidou.mybatisplus.core.conditions.AbstractLambdaWrapper.getColumn(AbstractLambdaWrapper.java:xxx) at com.baomidou.mybatisplus.core.conditions.AbstractWrapper.eq(AbstractWrapper.java:xxx) at com.xxx.order.service.OrderService.listPaid(OrderService.java:xx)

第一行是被抛出的位置，第二行说明"我要把 lambda 转成列名，但拿不到这个实体的列缓存"，第三行是我们调用的eq。而整个堆栈里没有org.apache.ibatis，没有SqlSession，没有DataSource——这恰好是最有价值的线索：问题出在 MyBatis-Plus 的条件构造层，而不是真正执行 SQL 的那一层。

另外提一句，异常类型在不同版本里可能是MybatisPlusException，也可能是IllegalArgumentException或者IllegalStateException，取决于这个版本里Assert.notNull的实现抛的是什么。但 message 完全一致，都是can not find lambda cache for this entity [...]。所以别按异常类型去搜，直接搜 message 更靠谱。

1.3 线上跑得好好的，为什么单测就翻车

同一个 Service，扔进@SpringBootTest里跑得好好的，扔进纯 Mockito 单测就炸。这个反差才是问题的核心。

原因在于 MyBatis-Plus 的 lambda 列名映射表，是在应用启动阶段扫描 Mapper 的时候一次性写入的。启动流程走完，表里已经有Order -> {orderNo: order_no, status: status, ...}这样的映射，之后你无论在哪儿Wrappers.lambdaQuery().eq(Order::getOrderNo, ...)，都只是查表取值，稳定得很。

而纯 Mockito 单测里，OrderMapper是 Mockito 用字节码生成的一个假实现，它没有被注册进任何Configuration，也就没有触发"扫描 Mapper 顺带注册实体元数据"这一步。Spring 没起来，Mapper 没被扫，表就是空的。你在一个空表上查列名，自然会拿到那个异常。

提示：判断标准很简单——只要你的单测没有启动 Spring 上下文，也没有手动初始化过 MyBatis-Plus 的Configuration，那么任何Wrappers.lambdaQuery()、Wrappers.lambdaUpdate()对实体字段的引用都会踩这个坑。

2. 顺着 LambdaUtils 往下挖：lambda cache 到底是谁写的

2.1 从 SFunction 到列名，中间隔着两次查表

要讲清楚这个报错，得先知道Order::getOrderNo这个方法引用是怎么变成order_no的。MyBatis-Plus 的SFunction接口继承了Serializable，编译器会为 lambda 生成一个writeReplace方法，运行时通过它拿到java.lang.invoke.SerializedLambda，从中读取getImplMethodName()——也就是getOrderNo。剥掉get前缀再首字母小写，得到属性名orderNo。

但这只是第一步。属性名到列名之间还有一次查表，因为一个实体的列名可能被@TableField("order_no")显式改写，也可能受全局下划线策略影响。所以AbstractLambdaWrapper#getColumn的实际逻辑是：拿到实体 Class，先查这个 Class 的列缓存 Map，再从 Map 里按属性名取列名。这两步中任何一步取不到值，都会抛出异常。

这里就产生了两种表现完全不同的报错：

看出区别了吧。第一种是"这个类我压根不认识"，第二种是"这个类我认识，但你说的这个字段我不认识"。我遇到的大部分线上问题都是第一种，而且九成都发生在测试环境。分清这两句话，排查方向能省一大半时间。

2.2 TableInfo 的写入时机，全在启动阶段

列缓存的源头是TableInfo。每个实体类在 MyBatis-Plus 里都对应一个TableInfo对象，记录表名、主键、字段列表、字段与列的对应关系、逻辑删除配置等等。这个对象一旦构建完成，就会被TableInfoHelper放进一张以类全限定名为 key 的静态缓存里，供后续所有包装器查询。

那它是什么时候构建的？答案是 MyBatis-Plus 接管了 MyBatis 的 Mapper 解析流程。当Configuration.addMapper(...)被调用时，MyBatis-Plus 用自己的MybatisMapperAnnotationBuilder解析这个 Mapper 接口，解析过程中会解析接口上的泛型参数，取出它操作的那个实体类，然后调用TableInfoHelper.initTableInfo(builderAssistant, entityClass)完成注册。整个过程发生在应用启动、Mapper 被扫描的那一刻。

这条链路带来两个很重要的推论：

• 注册是声明式、顺带完成的。你从来没写过一行注册代码，是因为启动流程替你做了。
• 注册是有前提的。得有人调用addMapper，还得有一个Configuration和一个MapperBuilderAssistant。少了任何一环，注册就不会发生。

顺带说，正因为它是静态缓存，所以在同一个 JVM 里跑多个测试类时，缓存会跨测试类残留。这个特性后面会变成一个隐蔽的坑。

2.3 Mock 之后，链路到底断在了哪一环

把上面两条串起来看就很清楚了。正常启动时链路是：

MybatisSqlSessionFactoryBean构建MybatisConfiguration→ 扫描@MapperScan指定的包 → 对每个 Mapper 接口调用configuration.addMapper(...)→MybatisMapperAnnotationBuilder.parse()→TableInfoHelper.initTableInfo(assistant, Order.class)→ 缓存写入。

而纯 Mockito 单测里，OrderMapper由 Mockito 动态生成，MybatisConfiguration根本不存在，addMapper没有被调用，initTableInfo没有被执行。断点就在最开头——MybatisConfiguration压根没建。

还有一种更容易让人误判的情况：有同事说"我也用了@SpringBootTest啊，但我把 Mapper 用@MockBean替换掉了，为什么没事？"因为在@MockBean的场景下，Spring 上下文依然完整启动了一遍，MybatisConfiguration照样构建，Mapper 照样被扫描注册，@MockBean只是把容器里最终的 Bean 换成了假对象。注册这一步已经完成了，所以 lambda cache 是满的。

注意：区分"上下文是否启动"和"Bean 是否是真对象"，是判断这类问题的分水岭。@Mock配合@ExtendWith(MockitoExtension.class)不启动上下文，@MockBean启动上下文。这一字之差，决定了你有没有 lambda cache。

3. 三种修法的取舍：从手工灌缓存到真启动一次

3.1 方案 A：手工调用 initTableInfo，最轻量

既然是注册这一步没做，那就手动把它补上。这是改动面最小、执行最快的方案，适合只想让单测跑起来的场景：

import com.baomidou.mybatisplus.core.MybatisConfiguration; import com.baomidou.mybatisplus.core.config.GlobalConfig; import com.baomidou.mybatisplus.core.metadata.TableInfoHelper; import com.baomidou.mybatisplus.core.toolkit.GlobalConfigUtils; import org.apache.ibatis.builder.MapperBuilderAssistant; public final class MpTableInfoInitializer { private MpTableInfoInitializer() { } public static void init(Class<?>... entityClasses) { MybatisConfiguration configuration = new MybatisConfiguration(); GlobalConfig globalConfig = new GlobalConfig(); globalConfig.setBanner(false); GlobalConfigUtils.setGlobalConfig(configuration, globalConfig); MapperBuilderAssistant assistant = new MapperBuilderAssistant(configuration, ""); assistant.setCurrentNamespace("mp.test.initializer"); for (Class<?> entityClass : entityClasses) { TableInfoHelper.initTableInfo(assistant, entityClass); } } }

然后在测试里：

@BeforeAll static void initMpMetadata() { MpTableInfoInitializer.init(Order.class); }

为什么这样能修好？因为initTableInfo干的事情就是构建TableInfo并写入缓存，和启动时扫描 Mapper 触发的那一步完全等价。差别只在于启动时是"顺带"触发的，这里是我们主动调用的。

有两点必须留意。第一，MapperBuilderAssistant的currentNamespace最好显式设一下，留空在某些版本里会让builderAssistant.getConfiguration()相关的默认值拼装出现意外行为。第二，initTableInfo的重载签名在不同版本里不一样，3.5.x 之后多了带existTable参数的重载，如果你用的是较新版本且编译不通过，去看一眼自己依赖里的源码，别照抄博客。

稍微绕一点但更省事的变体是直接让 MyBatis 去扫一次 Mapper 接口：

MybatisConfiguration configuration = new MybatisConfiguration(); GlobalConfigUtils.setGlobalConfig(configuration, new GlobalConfig()); configuration.addMapper(OrderMapper.class);

addMapper内部会走完整的解析流程，顺带把实体注册了。好处是不用一个个列实体类，坏处是如果 Mapper 上写了@Select这类注解 SQL，解析过程会一并处理，遇到语法或者占位符问题可能抛出别的异常，反而干扰判断。纯 Mockito 场景下两种都行，看你好维护哪一种。

3.2 方案 B：测试里搭一个真的 SqlSessionFactory

如果你希望测试环境下的元数据和线上完全一致，最稳妥的做法是别手工拼GlobalConfig，而是复用生产的那份配置。核心思路是在测试里构建一个MybatisSqlSessionFactoryBean，指向同一套mapper-locations和configuration配置项，数据源可以用内存库顶上，也可以只做元数据注册而完全不执行 SQL。

这么做最大的价值是消除配置漂移。手工new GlobalConfig()用的是默认值，如果你的生产配置里改过db-config下的下划线开关、主键生成策略、逻辑删除字段名这些，测试环境下的列名映射就会和生产不一致。平时看不出问题，一旦你的单测里有断言 SQL 片段或者参数值的代码，立刻就会对不上。

我通常的取舍是：只想验证 Service 分支逻辑的，用方案 A，快；需要验证包装器拼出来的条件确实正确的，用方案 B 或者干脆走集成测试，稳。

3.3 方案 C：接受它是个集成测试，用内存库跑

还有一种思路是承认"包装器到 SQL 的转换"本来就不是单元测试该覆盖的范围。它在语义上依赖框架的元数据装配，你把它硬塞进不启动上下文的单测里，等于是在测框架而不是测自己的代码。

如果项目里引入了mybatis-plus-boot-starter-test，它提供的@MybatisPlusTest注解可以直接拉起一个只加载 MyBatis-Plus 相关 Bean 的轻量上下文，配合内存库就能跑。相比完整的@SpringBootTest，它启动更快，而且顺带把分页插件之类的拦截器也装上了。

说到分页，这里必须提醒一句：网上很热的"MyBatis-Plus 分页失效"话题，有一部分探针就指向测试环境。纯 Mockito 单测里分页拦截器根本没被注册，Page对象返回的total、pages永远是默认值，你在这种测试里断言分页结果等于什么都没测。要验证分页，就必须走带拦截器的集成测试路线。

3.4 三种方案怎么选

我的实际选择通常是这样：日常的 Service 单测固定用方案 A，但会把init调用收进一个基类里；遇到包装器相关的断言需求，切到方案 C，不去为难方案 A。

4. 我在实际修这个问题时踩过的坑

4.1 GlobalConfig 没设，列名和生产悄悄错开了

第一次写工具类时我图省事，直接new MapperBuilderAssistant(new MybatisConfiguration(), "")就调initTableInfo，跑通了，很高兴。结果两天后有个测试开始莫名其妙地失败，断言 SQL 片段里期待的是order_no，实际拿到的是orderNo。

排查半天才想起来：我们的生产配置里关掉了下划线转换，字段名和列名靠@TableField显式声明来对应。手工 new 出来的GlobalConfig用的是框架默认值（下划线转换是开的），于是同一个实体在测试环境解析出来的列名和生产环境不是一回事。

教训很直接：只要你的测试里出现对列名、SQL 片段的断言，就必须让测试环境的GlobalConfig.DbConfig和生产保持一致。要么显式设置，要么直接复用生产的配置对象。

4.2 静态缓存跨测试类污染，出现了顺序依赖

这张缓存是静态的，同一个 JVM 内跨测试类共享。于是就出现了这样的现象：OrderServiceTest单独跑必挂，mvn test全量跑却全绿；或者反过来，调整一下测试类执行顺序，原本绿的测试开始红。

本质上这是测试之间的隐式耦合——A 测试类初始化了Order的元数据，B 测试类"蹭"到了这份缓存，于是 B 看起来不需要初始化。哪天 A 被删掉或者被跳过，B 立刻暴雷。

处理办法是给每个需要元数据的测试类都显式初始化，别指望别人给你铺路。如果依赖的版本里提供了清理缓存的方法（不同版本 API 不一样，用之前先翻源码确认），可以在@BeforeEach里清一次再初始化，保证每个用例都从干净状态出发——注意清完必须重新注册，否则你会看到一个更诡异的报错。

4.3 多数据源场景下只注册了一半

项目用了多数据源，主库和从库各有一套Configuration。我一开始只在主配置里补了注册，从库那套的实体启动时报同样的错，但只在从库相关的测试里出现。

根本原因是元数据是按Configuration维度各自维护的，你给哪个Configuration注册了，哪个才有。多数据源场景下，每个数据源对应的那套配置都得单独初始化，不能用一把梭的写法。

4.4 属性级报错：不是缓存没写，是字段本来就不该在里面

讲一个容易混淆的变体。有一次报的是can not find lambda cache for this property [extInfo] of entity [Order]，看到 entity 后面带了方括号里的类名，我就以为是同一个问题，继续按"没注册"的思路查，查了两小时毫无进展。

后来才反应过来，这句话的结构不一样：它说的是 property 找不到，不是 entity 找不到。也就是说，Order的缓存是有的，只是extInfo这个属性不在里面。翻了一下实体定义，这个字段标了@TableField(exist = false)——它本来就不是数据库字段，天然不会进入列名映射。这种字段在包装器里被引用，就是设计层面的错误用法。

所以记住：报 entity 找不到，查注册；报 property 找不到，查这个字段是不是真的持久化字段，或者 getter 是不是手写的非标准命名。

4.5 版本差异，别照抄任何一篇博客

最后说一个元坑。MyBatis-Plus 在 3.4.x 到 3.5.x 之间重构了 lambda 解析部分，早期LambdaUtils.extract直接返回SerializedLambda，后期引入了LambdaMeta抽象，还区分了反射实现和影子实现；TableInfoHelper.initTableInfo的参数列表也变过。再加上mybatis-plus和mybatis-plus-boot-starter两个坐标混用时可能出现版本不一致，你复制网上的修复代码编译不过，或者编译过了行为不对，都很正常。

提示：遇到这类问题，最省时间的动作是打开 IDE，按住 Ctrl 点进LambdaUtils和TableInfoHelper的源码，看清楚你这个版本的方法签名和抛异常的判断条件。这一步花三分钟，能省掉后面三小时的试错。

5. 更稳的写法：让单测不再依赖 lambda cache

5.1 把包装器构造从被测逻辑里剥出来

从设计角度讲，让纯 Mockito 单测去构造 lambda 包装器，本身就是在给测试引入框架依赖。更干净的思路是把这个构造动作抽出去：

public interface OrderWrapperFactory { LambdaQueryWrapper<Order> paidBy(String orderNo); }

Service 依赖这个接口，单测里 Mock 掉工厂返回一个预置的包装器，Service 里剩下的就是纯粹的分支逻辑，跟 MyBatis-Plus 一点关系都没有，跑得飞快也永远不会因为这个错挂掉。工厂本身用集成测试去覆盖，各管一段。

另一种极端做法是单测里改用字符串列的QueryWrapper：

QueryWrapper<Order> wrapper = new QueryWrapper<Order>() .eq("order_no", orderNo) .eq("status", 1);

这种写法不需要查列名映射，所以纯单测里完全能用。代价是丢掉了编译期检查，列名拼错要等到集成测试甚至上线才发现，我不太推荐在业务代码里这么写，但在测试辅助代码里偶尔用一下是可以接受的。

5.2 用 ArgumentCaptor 断言条件内容，而不是断言条件类型

既然测试已经跑起来了，顺手把断言写扎实一点。常见的坏写法是：

verify(orderMapper).selectList(any(LambdaQueryWrapper.class));

这只验证了"调过一次、参数类型对"，条件对不对完全没覆盖。改成抓取参数再检查内容：

ArgumentCaptor<Wrapper<Order>> captor = ArgumentCaptor.forClass(Wrapper.class); verify(orderMapper).selectList(captor.capture()); Wrapper<Order> wrapper = captor.getValue(); assertThat(wrapper.getSqlSegment()).contains("order_no"); assertThat(wrapper.getParamNameValuePairs()).containsValue("NO-20240101"); assertThat(wrapper.getParamNameValuePairs()).containsValue(1);

这里有个细节值得注意：getSqlSegment()出来的不是最终 SQL，参数位置是占位符（类似#{ew.paramNameValuePairs.MPGENVAL1}），真正的值在getParamNameValuePairs()里。所以断言要分两处做，一个查列名片段，一个查参数值。只查前者，条件写错了值你也发现不了；只查后者，列名拼错了你也发现不了。参数类型上建议用Wrapper接口而不是具体实现类，避免哪天内部换个包装器实现就把测试搞挂。

5.3 用 JUnit 5 扩展统一初始化

如果决定走方案 A，最好别在每个测试类里写@BeforeAll，而是收进一个扩展，通过@ExtendWith挂上去：

public class MpMetadataExtension implements BeforeAllCallback { @Override public void beforeAll(ExtensionContext context) { MpTableInfoInitializer.init( Order.class, OrderItem.class, Payment.class ); } }

用的时候：

@ExtendWith({MockitoExtension.class, MpMetadataExtension.class}) class OrderServiceTest { // ... }

这么做的好处是初始化清单集中在一处，新加实体只需要改一个地方。缺点是这份清单会随着项目膨胀，需要有人维护；如果实体数量很多，可以考虑按测试类声明需要的实体，而不是全局一把梭。

5.4 别忘了断言之外的正确性

我见过不少修复案例，测试绿了但其实是假的绿。典型的两种：一是只跑了listPaid的返回值为空集合的分支，压根没走到条件拼装那一步，那么你补的初始化到底奏没奏效根本没被验证；二是把when(orderMapper.selectList(any()))的桩打得太宽，任何参数都返回同一个结果，条件写错了测试照样过。

验证修复是否真的生效，最直接的办法是先故意不调初始化，确认测试确实报can not find lambda cache，加上初始化后再跑，确认异常消失且断言全部通过。一红一绿，才能证明你改的是对的地方。

6. 修完之后怎么确认真的修好了

6.1 三个必须验证的点

第一，单独执行这个测试类能过，而不是依赖全量跑时其他测试类留下的缓存。在 IDE 里右键当前类单独 Run 一次，这是最容易被忽略也最容易暴露问题的验证方式。

第二，干净构建下能过。mvn clean test或者等价命令跑一遍，确认不是增量编译残留的 class 文件在起作用。

第三，配置一致性。如果你的断言里出现了具体列名或者参数值，确认测试环境解析出来的列名和生产一致，尤其是改过下划线策略、用了@TableField显式声明列名、配置了表前缀的项目。

6.2 一张速查表

这套排查逻辑我用了一年多，基本上看到 message 就能定位到类别，再按表往下走，很少超过十分钟。真正花时间的从来不是修，而是被那句"can not find lambda cache"带着往缓存方向跑偏。我现在遇到类似报错的第一个动作，是先把"谁负责写这份数据、什么时候写"问清楚，再去怀疑数据本身——这个习惯在我处理过的框架类问题里，命中率高得吓人。