文章目录
- MyBatis-Plus 单元测试中 Lambda Mock 的坑与解决
- 一、问题现象：一个很“莫名其妙”的异常
- 二、先给结论（重要）
- 三、问题根源：Lambda 缓存 + Mock = 翻车现场
- 1️⃣ MyBatis-Plus 的 Lambda 是“有状态”的
- 2️⃣ 单元测试里的 Mapper 是“假的”
- 四、最小 Demo：错误 vs 正确
- ❌ 错误示例（非常常见）（高概率翻车）
- ✅ 实测最稳方案（推荐）
- 业务代码调整（关键）
- 对应单元测试
- 五、一个重要认知：单元测试不该关心 SQL 细节
- ❓ 单元测试应该测什么？
- ❌ 不应该在单元测试里测什么？
- 六、如果“我就是想用 Lambda”，怎么办？
- 方案：手动触发 Lambda 缓存初始化
- 七、真实项目中的推荐测试分层
- 八、顺手避坑：UnnecessaryStubbingException
- ❌ 常见反例
- ✅ 正确做法：按需 Mock
- 九、总结（请记住这 3 句话）
MyBatis-Plus 单元测试中 Lambda Mock 的坑与解决
核心主题：
单元测试里 Mock MyBatis-Plus Mapper 时，为什么一用LambdaQueryWrapper / LambdaUpdateWrapper就报错？
以及：如何用最简单、最稳妥的方式解决它。
一、问题现象：一个很“莫名其妙”的异常
很多人在写 MyBatis-Plus 单元测试时，都见过下面这个异常：
MybatisPlusException: can not find lambda cache for this entity [com.example.domain.User]它通常出现在：
- 使用
LambdaQueryWrapper - 使用
LambdaUpdateWrapper - Mapper 被 Mockito
@Mock或@MockBean
而线上环境完全没问题，只有单元测试会炸。
这类问题非常典型，也非常让人困惑。
二、先给结论（重要）
99% 的场景下，这不是你业务代码的问题，而是 Mock 方式不当。
最稳妥、最推荐的做法只有一句：⚠️ 折中方案（不完全可靠）
when(userMapper.update(any(),any())).thenReturn(1);- 在很多项目中可用
- 但在某些 MyBatis-Plus 版本 / 复杂测试场景下
- 仍可能失败
而不是：
// ❌ 非常容易触发 Lambda cache 异常when(userMapper.update(any(User.class),any(LambdaUpdateWrapper.class))).thenReturn(1);下面我们一步一步解释：为什么会这样，以及为什么any()能救命。
三、问题根源：Lambda 缓存 + Mock = 翻车现场
1️⃣ MyBatis-Plus 的 Lambda 是“有状态”的
MyBatis-Plus 的 Lambda 写法并不是语法糖，它背后依赖一个Lambda 缓存：
- 通过
User::getId解析出字段名id - 解析结果会缓存在内部
LambdaCache - 这个缓存和实体类的 Class、类加载器、初始化时机强相关
一句话总结：
LambdaWrapper 不是一个普通 POJO，它在构造时就依赖 MyBatis-Plus 的运行环境。
2️⃣ 单元测试里的 Mapper 是“假的”
在单元测试中我们通常这样写：
@ExtendWith(MockitoExtension.class)classUserServiceTest{@MockprivateUserMapperuserMapper;}此时：
- Mapper 是 Mockito 生成的代理对象
- 不存在真实的 MyBatis 上下文
- Lambda 缓存可能根本没初始化
但你却在 Mock 时强行写：
any(LambdaUpdateWrapper.class)👉 Mockito 会尝试去解析这个参数类型
👉 MyBatis-Plus 会尝试读取 Lambda 缓存
👉 然后发现：缓存不存在
于是，异常就出现了。
四、最小 Demo：错误 vs 正确
❌ 错误示例（非常常见）（高概率翻车）
@TestvoidtestDeleteUser(){when(userMapper.update(any(User.class),any(LambdaUpdateWrapper.class))).thenReturn(1);booleanresult=userService.deleteUser(1L);assertTrue(result);}问题点只有一个：
你在单元测试里，强依赖了
LambdaUpdateWrapper的内部机制。
✅ 实测最稳方案（推荐）
单元测试中：彻底避免 LambdaWrapper。
业务代码调整（关键）
// ❌ 原写法LambdaUpdateWrapper<User>wrapper=newLambdaUpdateWrapper<>();wrapper.eq(User::getId,userId);// ✅ 推荐写法UpdateWrapper<User>wrapper=newUpdateWrapper<>();wrapper.eq("id",userId);对应单元测试
@Test@DisplayName("删除用户 - 成功")voidtestDeleteUser(){when(userMapper.update(any(),any())).thenReturn(1);booleanresult=userService.deleteUser(1L);assertTrue(result);}为什么它最稳？
QueryWrapper / UpdateWrapper是普通对象- 不依赖 Lambda 缓存
- 不依赖实体元数据初始化
- 与 Mockito / 测试环境完全解耦
👉 *这是目前实践中稳定性最高、成本最低的方案。
五、一个重要认知：单元测试不该关心 SQL 细节
很多 Lambda Mock 问题，本质是测试关注点放错了。
❓ 单元测试应该测什么？
- 业务逻辑是否正确
- 条件成立时是否调用了 Mapper
- 返回值是否被正确处理
❌ 不应该在单元测试里测什么？
- LambdaWrapper 拼了哪些字段
- SQL 是否正确
- 条件构造是否符合预期
👉这些是集成测试 / Mapper 测试的职责。
六、如果“我就是想用 Lambda”，怎么办？
有，但不推荐。
方案：手动触发 Lambda 缓存初始化
@TestvoidtestWithLambdaInit(){// 触发一次 Lambda 解析newLambdaQueryWrapper<User>().select(User::getId);when(userMapper.selectList(any())).thenReturn(List.of());List<User>users=userService.list();assertNotNull(users);}缺点非常明显：
- 测试代码变脏
- 可读性下降
- 仍可能受类加载器影响
👉只在极少数必须验证 Lambda 行为的场景下使用。
七、真实项目中的推荐测试分层
单元测试（Service） - Mock Mapper - 一律 any() - 只测业务分支 集成测试（Mapper / DB） - 真数据库 / Testcontainers - 真 LambdaWrapper - 验证 SQL 行为不要试图在一个测试里干两件事。
八、顺手避坑：UnnecessaryStubbingException
❌ 常见反例
@BeforeEachvoidsetUp(){when(cryptoKeyProvider.getMasterKey()).thenReturn(key);}但某些测试根本用不到它。
✅ 正确做法：按需 Mock
@TestvoidtestCreateUser(){when(cryptoKeyProvider.getMasterKey()).thenReturn(key);when(userMapper.insert(any())).thenReturn(1);}👉Mock 写在测试里，而不是统一写在@BeforeEach。
九、总结（请记住这 3 句话）
- LambdaWrapper 在单元测试里是“高危对象”
- Service 单测中，
any()是最优解 - SQL 正确性不属于单元测试的职责
如果你在单测里看到：
can not find lambda cache别急着怀疑人生，先看看你是不是写了：
any(LambdaUpdateWrapper.class)改成any()，世界大概率就清净了。
