背景说明
最近在搭建一个新的后端脚手架，技术栈选用了 Spring Boot 3.2.5 搭配 MyBatis-Plus。
在项目初始化阶段，我习惯使用 IDEA 的 MyBatisX 插件来一键生成 Entity、Mapper 和 Service 层代码。但在这次引入了较新的 MyBatis-Plus 3.5.17 版本后，却遇到了一个非常诡异的问题：代码生成器生成的 IService 和 ServiceImpl 居然全部爆红，提示找不到包。
经过一番排查和翻阅源码，发现这并不是代码生成器的 Bug，而是 MyBatis-Plus 在新版本中进行了一次破坏性的架构重构。特此记录，帮大家避坑。
异常重现
在使用 MyBatisX 生成代码后，Service 层的接口和实现类会出现如下报错：
// 爆红，提示 Cannot resolve symbol 'extension'
import com.baomidou.mybatisplus.extension.service.IService;
import com.baomidou.mybatisplus.extension.service.impl.ServiceImpl;
核心原因剖析：包路径重构
在 MyBatis-Plus 3.5.15 及更早的历史版本中，IService 和 ServiceImpl 等类是放在 extension 包下的。这意味着 MyBatis-Plus 的核心功能与 Spring 框架是存在一定程度的强耦合的。
为了让框架更加纯粹，MyBatis-Plus 团队在后续的版本（3.5.17 及之后）中做了一次底层架构调整：将只属于 Spring 相关的接口和实现类，独立抽取到了 mybatis-plus-spring 这个模块中。
因此，这两个核心类的包路径发生了根本性的改变：
为什么 MyBatisX 插件生成的代码会报错？
因为目前市面上很多代码生成器插件（包括常用的 MyBatisX）或者网上的旧版自动生成脚本，其底层模板依然写死的是旧版的 extension 路径。当我们引入 3.5.17 版本的依赖时，自然就找不到旧包了。
解决方案
针对这个问题，有两个解决方案，大家可以根据自己的项目所处的阶段进行选择。
方案一：降级到 3.5.15（强烈推荐）
如果你不想每次用插件生成代码后都要手动去全局替换导包路径，最稳妥的做法就是将依赖降级到 3.5.15。
3.5.15 是架构大重构前极其稳定的一个“黄金版本”，完美兼容 Spring Boot 3.x。目前全网 99% 的教程和开源插件，默认支持的都是这个包路径。
修改 pom.xml，锁定版本号：
<dependency>
<groupId>com.baomidou</groupId>
<artifactId>mybatis-plus-spring-boot3-starter</artifactId>
<version>3.5.15</version> <!-- 锁定这个稳定版本 -->
</dependency>
方案二：拥抱新版本，修改生成器配置
如果你坚持要使用 3.5.17 或更新的版本，你需要做好以下适配工作：
修复已有代码： 在 IDEA 中使用全局搜索替换功能（
Ctrl + Shift + R），将项目里所有的.extension.service替换为.spring.service。更新代码生成器模板： 如果你使用的是纯 Java 代码配置的
FastAutoGenerator，需要检查并更新你的模板文件（如 Velocity 或 Freemarker 模板），修改里面的 import 路径。如果你使用的是 MyBatisX 插件，短期内可能需要等待插件作者发布更新来适配新路径，或者每次生成后手动替换一次。
总结
在从 Spring Boot 2 升级到 Spring Boot 3 的过程中，不仅要注意 Jakarta EE 的命名空间替换，也要警惕像 MyBatis-Plus 这类周边生态组件的底层重构。选择一个生态兼容性最好的稳定版本（如 3.5.15），往往能让我们把更多的精力聚焦在核心业务的开发上。