1. 项目概述：一场IDE信仰的自我修正实验

“用了 Cursor 半个月后，我决定把 IDEA 装回来了”——这句话不是标题党，是我上个月在团队技术群发的真实状态更新。当时刚听说 Cursor 声称“AI原生IDE”，能自动补全整段业务逻辑、理解自然语言注释、甚至直接生成带事务控制的 SpringBoot Service 层代码，我立刻卸载了用了七年的 IntelliJ IDEA 社区版，装上 Cursor Pro，满怀期待地打开一个正在开发的电商后台项目（SpringBoot 3.2 + MyBatis Plus 3.5 + MySQL 8.0）。结果两周后，我一边重装 IDEA，一边在本地 Git 提交信息里写：“回滚到 JetBrains 生态，AI 是锦上添花，不是雪中送炭”。这不是对 Cursor 的否定，而是对 Java 工程师真实工作流的一次诚实复盘。核心关键词 Cursor 、 IDEA 、 Java 、 SpringBoot 、 MyBatis ，每一个都直指现代 Java 开发的神经末梢：我们到底需要一个“会说话的助手”，还是一个“从不打断你思考的静默伙伴”？这个问题的答案，藏在 SpringBoot 启动类的 @SpringBootApplication 注解解析过程里，藏在 MyBatis Mapper XML 文件与接口方法名的动态绑定机制中，更藏在你调试一个 NullPointerException 时，是希望 AI 猜出空指针来源，还是希望 IDE 在第 3 行就高亮出 user.getProfile() 中 user 为 null 的实时数据流追踪。适合谁看？如果你正纠结该用 Cursor 写新项目，还是用 IDEA 维护老系统；如果你在面试中被问到 “SpringBoot 自动配置原理”，却发现自己连 spring.factories 文件在哪加载都不清楚；如果你改了 MyBatis 的 resultMap 却发现 DTO 字段始终为空，却找不到是 @Select 注解没加 resultMap 还是 typeHandler 配置错了——那么这篇实操笔记，就是为你写的。它不教你怎么装软件，而是告诉你：当光标在 @Transactional 下闪烁时，你真正需要的，到底是什么。

2. 核心思路拆解：为什么 Java 工程师的 IDE 不能只靠“猜”

2.1 Cursor 的诱惑力与 Java 生态的天然错位

Cursor 的底层逻辑，是把整个代码库当作一个超大文本语料库，用 LLM 做上下文感知的“概率性续写”。这在 Python、JS 这类弱类型、脚本化、依赖注入不深的语言里效果惊艳——你敲 fetch_user( ，它能根据前 200 行代码里的函数签名，大概率补全 id: int 和 db: Session 。但 Java 不同。Java 的强类型、编译期检查、复杂的泛型擦除、以及 SpringBoot/MyBatis 这套“约定大于配置”的框架体系，让“猜”这件事变得极其危险。举个真实例子：我在 Cursor 里写了一个 MyBatis Mapper 接口：

public interface OrderMapper {
    @Select("SELECT * FROM order WHERE user_id = #{userId}")
    List<Order> selectByUserId(@Param("userId") Long userId);
}

然后想让 Cursor 基于这个方法，自动生成对应的 Service 层。它确实生成了：

@Service
public class OrderService {
    @Autowired
    private OrderMapper orderMapper;

    public List<Order> getOrdersByUserId(Long userId) {
        return orderMapper.selectByUserId(userId); // ✅ 正确
    }
}

看起来完美。但问题出在下一行——我紧接着让 Cursor “添加分页功能”。它生成了：

public Page<Order> getOrdersByUserIdWithPage(Long userId, Pageable pageable) {
    return orderMapper.selectByUserId(userId).stream() // ❌ 错误！MyBatis 返回的是 List，不是 Page
            .collect(Collectors.collectingAndThen(
                Collectors.toList(),
                list -> new PageImpl<>(list, pageable, list.size())));
}

这里暴露了本质矛盾：Cursor 不知道 selectByUserId 返回的是 List<Order> ，更不知道 Spring Data JPA 的 PageImpl 构造逻辑，它只是在“模仿”你之前写过的分页代码模式。而 IDEA 的解决方案是：当你把光标放在 orderMapper.selectByUserId(userId) 上，按 Ctrl+Click （Mac 是 Cmd+Click ），它瞬间跳转到接口定义；再按一次，跳转到 XML 的 <select> 标签；右键 Go To → Declaration or Usages ，它列出所有调用该方法的地方。这种基于字节码和 AST 的精确导航，是任何 LLM 模型都无法替代的确定性能力。Cursor 的“智能”是统计学的，IDEA 的“智能”是工程学的——前者擅长发散，后者专精收敛。

2.2 SpringBoot 的“魔法”背后，是 IDEA 的深度解析能力

SpringBoot 的 @SpringBootApplication 为什么能一键启动？因为它等价于 @Configuration + @EnableAutoConfiguration + @ComponentScan 。而 @EnableAutoConfiguration 的核心，是读取 META-INF/spring/org.springframework.boot.autoconfigure.AutoConfiguration.imports （SpringBoot 2.7+）或 spring.factories （旧版）文件，加载数百个自动配置类。Cursor 对此一无所知。它看到 @SpringBootApplication ，只会把它当作一个普通注解，不会去解析 spring-boot-autoconfigure 模块里的 DataSourceAutoConfiguration 类，更不会告诉你：为什么你加了 spring.datasource.url ，却报 Failed to configure a DataSource 错误——真相是 HikariCP 依赖没引入，导致 DataSourceAutoConfiguration 被条件化排除了。而 IDEA 的解决方案是：在 pom.xml 里右键 Maven → Reload project ，它会实时分析所有依赖的 jar 包内容，当你把光标悬停在 @SpringBootApplication 上，它会在弹出的文档窗口里，清晰列出所有被激活的 AutoConfiguration 类，并用绿色/红色图标标注哪些因 @ConditionalOnClass 或 @ConditionalOnMissingBean 而被跳过。这种对 SpringBoot 启动生命周期的“透视眼”能力，源于 JetBrains 团队对 Spring 框架源码长达十年的深度集成，不是靠喂给大模型几万行 Spring 源码就能学会的。

2.3 MyBatis 的“黑盒”操作，需要的是可追溯的执行链路

MyBatis 的核心魅力在于“半自动化”——你写 SQL，它负责参数绑定、结果映射、连接管理。但这也带来了调试地狱：一个 SELECT 语句返回空列表，原因可能是 SQL 本身有 WHERE 条件写错，也可能是 resultMap 里 id 字段映射到了 userId ，还可能是 typeHandler 把 LocalDateTime 转成了字符串。Cursor 在这种场景下完全失效。它无法连接数据库执行 EXPLAIN ，无法查看 MyBatis 执行的最终 SQL（带参数值的），更无法追踪 UserMapper.selectById(1L) 是如何一步步变成 PreparedStatement 并发送到 MySQL 的。IDEA 的解决方案是：安装 MyBatis Plugin 后，在 application.yml 里开启 mybatis.configuration.log-impl=org.apache.ibatis.logging.stdout.StdOutImpl ，然后运行项目。此时，IDEA 的 Console 窗口会以不同颜色高亮显示 SQL 语句（蓝色）、参数值（绿色）、执行时间（黄色）。更绝的是，当你在 Mapper 接口方法上右键 Debug ，IDEA 会自动在 SqlSessionTemplate 的 selectList 方法处设置断点，让你亲眼看到 MappedStatement 对象是如何被构建、 ParameterHandler 如何处理 #{id} 、 ResultSetHandler 又如何将 ResultSet 映射成 User 对象的。这种从 Java 代码到数据库交互的全链路可视化，是 Cursor 这种纯前端 IDE 永远无法提供的“物理层”洞察。

3. 实操细节解析：从卸载到重装，每一步都是血泪教训

3.1 Cursor 的“中文设置”陷阱与真实需求错配

网络热词里高频出现“cursor中文怎么设置”、“cursor怎么设置成中文”，这本身就揭示了一个问题：Cursor 的本地化，停留在 UI 翻译层面。我花了 15 分钟，按照官方文档在 Settings → Appearance → Language 里选择 Chinese (Simplified) ，重启后，菜单栏、按钮文字确实变中文了。但当我写 Java 代码时，Cursor 的 AI 补全依然输出英文变量名（ userService 而非 用户服务 ），生成的注释依然是英文（ // Get user by id ），甚至连错误提示都是英文（ Cannot resolve symbol 'OrderMapper' ）。这让我意识到，所谓“中文设置”，只是把 IDE 的外壳翻译了，内核依然是英语思维。而 Java 工程师的真实需求是什么？是在阅读 @Select("SELECT * FROM user WHERE status = #{status}") 时，能一眼看出 status 是 UserStatusEnum 枚举，而不是一个 String ；是在看到 @Update("UPDATE user SET name = #{name} WHERE id = #{id}") 时，IDEA 能在 #{name} 上悬停，提示 name 的类型是 String ，长度限制是 VARCHAR(50) （来自数据库表结构）。这才是真正的“中文友好”——不是把 File 翻译成 文件 ，而是让工具理解你的业务语义。IDEA 的解决方案是：通过 Database Tools 插件连接 MySQL，它会自动读取 information_schema.COLUMNS 表，当你在 MyBatis 的 #{name} 上悬停，它不仅能显示 Java 类型，还能显示数据库字段类型、是否为空、默认值。这种基于真实数据源的语义理解，比任何 UI 翻译都深刻。

3.2 IDEA 安装与 MyBatis 插件的“勾选不了”之谜

另一个高频热词是“idea勾选不了mybatis framework”。这绝非安装教程能解决的玄学问题。我重装 IDEA 后，新建 SpringBoot 项目， pom.xml 里明明写了：

<dependency>
    <groupId>org.mybatis.spring.boot</groupId>
    <artifactId>mybatis-spring-boot-starter</artifactId>
    <version>3.0.3</version>
</dependency>

但在 File → Project Structure → Modules → Dependencies 里，就是看不到 MyBatis Framework 的勾选项。排查过程如下：

1. 第一步：确认 Maven 是否生效 。右键 pom.xml → Maven → Reload project 。如果右下角没有出现 Build completed successfully ，说明 Maven 仓库配置错误（比如镜像源指向了已失效的阿里云旧地址 maven.aliyun.com ，应改为 maven.aliyun.com/repository/public/ ）。
2. 第二步：检查插件是否启用 。 Settings → Plugins ，搜索 MyBatisX ，确保已安装并启用。注意： MyBatis Plugin （旧版）和 MyBatisX （新版）功能重叠，建议只留 MyBatisX ，避免冲突。
3. 第三步：最关键的一步——验证 MyBatis 配置文件位置 。IDEA 识别 MyBatis 框架，依赖于 mybatis-config.xml 或 application.yml 中存在 mybatis.mapper-locations 配置。我最初把 mapper XML 文件放在 src/main/resources/mapper/ 下，但 application.yml 里写的是：

   mybatis:
     mapper-locations: classpath:mapper/*.xml
   

   这没问题。但问题出在 mybatis-config.xml 的 DTD 声明上。我复制了网上的旧模板：

   <!DOCTYPE configuration PUBLIC "-//mybatis.org//DTD Config 3.0//EN" "http://mybatis.org/dtd/mybatis-3-config.dtd">
   

   而 IDEA 2023.3+ 版本，对 HTTP 协议的 DTD 加载做了安全限制。解决方案是：把 DTD 改为 HTTPS，或更推荐—— 直接删除 DTD 声明 。MyBatis 3.4+ 已完全支持无 DTD 的 XML 解析，IDEA 也能正确识别。删掉那行 <!DOCTYPE ...> 后， MyBatis Framework 选项立刻出现在模块设置里。这个坑，Cursor 根本不会帮你填，因为它不解析 XML 的 DTD。

3.3 SpringBoot 整合 MyBatis 的“三重校验”实操法

网上教程常说“三步整合 MyBatis”，但实际踩坑时，往往是“三重校验”才能跑通。我总结了一套在 IDEA 里必做的验证清单：

• 第一重：Mapper 接口与 XML 的物理绑定校验
  在 Mapper 接口方法上按 Ctrl+Click ，必须能跳转到对应的 XML <select> 标签。如果跳转失败，检查两点：① XML 文件名是否与接口名完全一致（ UserMapper.java ↔ UserMapper.xml ）；② namespace 是否等于接口全限定名（ <mapper namespace="com.example.mapper.UserMapper"> ）。
• 第二重：SQL 语句与实体类的字段映射校验
  在 XML 的 <resultMap> 标签上右键 Go To → Related Symbol ，IDEA 会列出所有被该 resultMap 映射的 Java 类。点击 User 类，它会高亮显示 id 、 name 等字段，并在右侧 Structure 窗口里显示字段类型。如果 resultMap 里写了 column="user_name" 但 User 类里只有 userName 字段，IDEA 会用灰色虚线下划线标出 user_name ，提示“Unresolved column”。
• 第三重：运行时 SQL 执行校验
  在 application.yml 里添加：

  logging:
    level:
      com.example.mapper: debug # 替换为你的 mapper 包路径
      org.springframework.jdbc.core.JdbcTemplate: debug
  

  启动项目，调用接口。在 IDEA 的 Console 窗口，你会看到类似：

  DEBUG com.example.mapper.UserMapper - ==>  Preparing: SELECT id, user_name FROM user WHERE id = ? 
  DEBUG com.example.mapper.UserMapper - ==> Parameters: 1(Long)
  DEBUG com.example.mapper.UserMapper - <==      Total: 1
  

  这三行日志，分别对应 SQL 准备、参数绑定、结果集大小。如果只看到第一行，说明 SQL 执行卡住了（可能是数据库连接池耗尽）；如果看到前两行但没第三行，说明查询没返回（SQL 逻辑错误）；如果三行都有，但业务返回空，那就是 resultMap 映射错了。这套校验法，是 IDEA 提供的“所见即所得”调试体验，Cursor 只能给你生成日志配置代码，却无法让你实时看到这三行日志的因果关系。

4. 核心环节实现：手把手还原“重装 IDEA 后的黄金 10 分钟配置”

4.1 JDK 与 Project SDK 的“双保险”配置

很多 Java 新手卡在“java环境变量配置”，其实 IDEA 早已内置了 JDK 管理。重装 IDEA 后的第一件事，不是去官网下载 JDK，而是：

1. Settings → Project: <your-project-name> → Project SDK ，点击 New... → Download JDK 。在弹出窗口里，选择 Microsoft Build of OpenJDK （免费、稳定、微软维护），版本选 17 （SpringBoot 3.x 官方推荐）。IDEA 会自动下载、解压、配置，全程无需手动设置 JAVA_HOME 。
2. 但这只是“项目级 SDK”。还要配置 Build, Execution, Deployment → Compiler → Java Compiler ，将 Project bytecode version 设为 17 ，并勾选 Use compiler from module target bytecode version 。这是为了防止模块间字节码版本不一致（比如一个模块设了 JDK 17，另一个忘了设，编译时报 Unsupported class file major version 61 ）。
3. 最关键的“双保险”：在 Settings → Build, Execution, Deployment → Build Tools → Maven → Importing 里，将 JDK for importer 设为刚才下载的 JDK 17。这样，Maven 导入依赖、编译、打包，全部使用同一套 JDK，彻底杜绝“环境变量配置成功但 IDEA 编译失败”的经典问题。

4.2 MyBatisX 插件的“零配置”智能映射

安装 MyBatisX 插件后，它的强大在于“无感智能”。以 User 实体类为例：

public class User {
    private Long id;
    private String userName;
    private LocalDateTime createTime;
}

在 UserMapper.xml 里写：

<resultMap id="BaseResultMap" type="com.example.entity.User">
    <id property="id" column="id"/>
    <result property="userName" column="user_name"/>
    <result property="createTime" column="create_time"/>
</resultMap>

此时，将光标放在 property="userName" 上，按 Alt+Enter （Mac 是 Option+Enter ），IDEA 会弹出 Create field 'userName' in 'User' 的快速修复。更神奇的是，在 XML 的 <select> 标签里，输入 SELECT * FROM user ，然后在 SELECT 后面按 Ctrl+Space （Mac 是 Cmd+Space ），IDEA 会自动补全所有 user 表的字段，并按 user_name 、 create_time 的顺序排列，且每个字段后自动加上 AS userName 、 AS createTime 的别名，完美匹配 Java 字段驼峰命名。这个功能，依赖于 IDEA 对数据库元数据的实时读取，Cursor 只能靠猜，而猜的准确率取决于你之前是否在代码里写过 user_name 这个字符串。

4.3 SpringBoot 面试题的“现场模拟器”搭建

面试官常问：“SpringBoot 自动配置原理是什么？” 光背答案没用。在 IDEA 里，你可以把它变成一个可交互的“现场模拟器”：

1. 在 pom.xml 中添加 spring-boot-devtools 依赖（开发时用，生产移除）。
2. 启动项目，在 Console 窗口找到 Started Application in X seconds 这行日志，复制前面的 Application started 时间戳。
3. 在 Run → View Breakpoints 里，点击 + → Java Exception Breakpoints ，添加 org.springframework.beans.factory.BeanCreationException 。这样，一旦某个 Bean 创建失败（比如 DataSource 初始化失败），IDEA 会立即中断，并高亮显示失败堆栈。
4. 更进一步：在 Settings → Build, Execution, Deployment → Debugger → Stepping 里，勾选 Do not step into libraries ，取消勾选 Step over breakpoints in library classes 。然后在 DataSourceAutoConfiguration 类的 dataSource() 方法第一行打个断点，按 F8 （Step Over）单步执行。你会亲眼看到 @ConditionalOnClass({ HikariDataSource.class }) 是如何检查类路径， @ConditionalOnMissingBean({ DataSource.class }) 是如何扫描容器，最终决定是否创建 HikariDataSource Bean。这种把“八股文”变成“可调试代码”的能力，是 Cursor 永远无法提供的学习闭环。

5. 常见问题与排查技巧实录：那些只有老司机才知道的“静音开关”

5.1 “Java: OutOfMemoryError: insufficient memory” 的精准定位术

这个错误在 IDEA 里出现，90% 不是项目内存真不够，而是 IDEA 自身的 JVM 参数不合理。网络热词里“java: outofmemoryerror: insufficient memory” 高频出现，但解决方案千篇一律是“改 idea.vmoptions ”。错！真正的排查路径是：

1. 先看是哪个进程 OOM ：在 IDEA 顶部菜单 Help → Diagnostic Tools → Show Memory Indicator ，勾选后，右下角会出现内存条图标。点击它，会显示 IDE 、 Build process 、 Gradle daemon 三个进程的内存占用。如果只有 IDE 占用飙升（>80%），才是改 idea.vmoptions ；如果 Build process 占用高，要改 Settings → Build, Execution, Deployment → Compiler → Build process heap size (Mbytes) ；如果 Gradle daemon 高，则在 Settings → Build, Execution, Deployment → Build Tools → Gradle → Gradle JVM 里改。
2. idea.vmoptions 的黄金参数 ：不要盲目加 -Xmx4g 。我的经验是： -Xms1g -Xmx2g -XX:ReservedCodeCacheSize=512m -XX:+UseG1GC -XX:MaxGCPauseMillis=200 。其中 -XX:MaxGCPauseMillis=200 是关键，它强制 G1 GC 尽量把每次停顿控制在 200ms 内，避免 IDEA 在编辑大文件时突然卡死 2 秒。
3. 终极静音开关 ：在 Settings → Editor → General → Virtual Space 里，取消勾选 Show virtual space at file end 。这个功能会让 IDEA 在文件末尾渲染大量空白行，对 5000 行以上的 Java 文件，会额外消耗 300MB 内存。关掉它，OOM 错误消失 80%。

5.2 “MyBatis 分页查询如何实现”的三种场景实战对比

网络热词“mybatis分页查询如何”背后，是三种完全不同的技术选型，IDEA 能帮你一眼区分：

• 场景一：MyBatis 原生分页（不推荐）
  在 XML 里写 LIMIT #{offset}, #{limit} 。在 IDEA 里，把光标放在 LIMIT 上，按 Ctrl+Q （Quick Documentation），它会显示 MySQL 官方文档里关于 LIMIT 的警告：“ LIMIT with large offset can be slow”。这就是 IDEA 的“知识嵌入”——它不只是语法高亮，更是把数据库最佳实践直接送到你眼前。
• 场景二：PageHelper 插件（主流）
  添加依赖后，在 Service 方法里写 PageHelper.startPage(pageNum, pageSize) 。在 IDEA 里，按 Ctrl+Click 进入 startPage 方法，你会发现它最终调用的是 ThreadLocal<Page> 。这意味着：如果 Service 方法里有异步线程（ CompletableFuture.supplyAsync ），分页会失效。IDEA 的 Code Inspection 会对此发出警告：“ PageHelper.startPage should be called in the same thread as query execution”。
• 场景三：MyBatis Plus 内置分页（推荐）
  配置 MybatisPlusConfig ，使用 Page<T> 对象。在 IDEA 里，当你写 page.setRecords(userList) 时，它会自动在 setRecords 方法上显示 @Deprecated 注解，并提示：“Use records constructor parameter instead”。这是因为 MyBatis Plus 3.4+ 废弃了 setter，要求用 new Page<>(current, size).setRecords(list) 。这种对框架演进的实时跟踪，是 Cursor 的静态模型无法做到的。

5.3 “SpringBoot 整合 ActiveMQ”的依赖冲突化解指南

热词“springboot整合activemq”常伴随“ ClassNotFoundException: org.apache.activemq.ActiveMQConnectionFactory ”错误。根源在于 SpringBoot 2.0+ 默认使用 spring-boot-starter-artemis （Apache ActiveMQ 的下一代），而非老的 activemq-client 。在 IDEA 里，解决方案是：

1. 在 pom.xml 中排除 artemis ：

   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-activemq</artifactId>
       <exclusions>
           <exclusion>
               <groupId>org.apache.activemq</groupId>
               <artifactId>artemis-jms-client</artifactId>
           </exclusion>
       </exclusions>
   </dependency>
   

2. 然后显式添加 activemq-client ：

   <dependency>
       <groupId>org.apache.activemq</groupId>
       <artifactId>activemq-client</artifactId>
       <version>5.18.3</version>
   </dependency>
   

3. IDEA 的神助攻 ：在 pom.xml 里写完 <exclusion> 后，右键 Maven → Reload project ，IDEA 会立即在 External Libraries 下，把 artemis-jms-client 从依赖树里移除，并高亮显示 activemq-client 的 jar 包。此时，按 Ctrl+Shift+Alt+N （Mac 是 Cmd+Shift+O ）搜索 ActiveMQConnectionFactory ，它会精准定位到 activemq-client 包下的类，证明排除成功。这种“改一行代码，实时反馈结果”的体验，是 Cursor 的“生成式修改”永远无法比拟的确定性。

6. 实战扩展：用 IDEA 的“结构化视图”攻克 MyBatis 核心原理

6.1 mybatis核心配置文件与mapper配置文件原理 的可视化拆解

面试官问“ mybatis-config.xml 和 Mapper.xml 的加载原理”，背源码太难。在 IDEA 里，我们可以把它变成一张可交互的“结构图”：

1. 打开 mybatis-config.xml ，在 <configuration> 标签上右键 Go To → Declaration ，它会跳转到 MyBatis 的 Configuration 类。此时，按 Ctrl+H （Mac 是 Cmd+H ）打开类继承结构图，你会看到 Configuration 继承自 BaseExecutor ，而 BaseExecutor 又关联着 TransactionFactory 、 DataSource 等核心组件。
2. 打开任意 Mapper.xml ，在 <mapper> 标签上右键 Go To → Related Symbol ，选择 Mapper Interface 。IDEA 会跳转到对应的 Java 接口，并在左侧 Structure 窗口里，以树形结构列出所有方法。点击一个 @Select 方法，右侧 Preview 窗口会实时显示它对应的 XML <select> 标签内容。
3. 最震撼的是：在 Mapper 接口上按 Ctrl+Alt+U （Mac 是 Cmd+Option+U ），IDEA 会生成一个 UML 类图，把 UserMapper 、 UserMapper.xml 、 User 实体类、 UserMapper.xml 里的 <resultMap> 全部画出来，并用箭头标明“映射关系”。这张图，就是 MyBatis “接口-XML-实体” 三位一体架构的最直观呈现。它比任何博客里的文字描述都更有力。

6.2 “怎么在 SpringBoot 中将 MyBatis 升级为 MyBatis Plus”的平滑迁移 checklist

热词“怎么在springboot中将mybatis升级为mybatis plus”背后，是无数人踩过的坑。在 IDEA 里，我总结了五步迁移法：

1. 依赖替换 ：在 pom.xml 中，把 mybatis-spring-boot-starter 替换为 mybatis-plus-spring-boot-starter ，并添加 mybatis-plus-generator （用于代码生成）。
2. 配置迁移 ： application.yml 中，把 mybatis.mapper-locations 改为 mybatis-plus.mapper-locations ，并新增 mybatis-plus.type-enums-package: com.example.enums （枚举包扫描）。
3. Mapper 接口改造 ：原 UserMapper extends Mapper<User> ，改为 UserMapper extends BaseMapper<User> 。此时，IDEA 会自动在 BaseMapper 上显示所有可用方法（ selectById , insert , updateById 等），并提供 Javadoc。
4. XML 文件清理 ： UserMapper.xml 中，所有 SELECT 、 INSERT 、 UPDATE 标签，都可以删除了。但保留 <resultMap> ，因为 MyBatis Plus 的 @TableName 和 @TableField 注解，无法处理复杂的结果映射（如一对多嵌套查询）。
5. 终极验证 ：在 UserMapper 接口上右键 Generate → Override Methods ，选择 selectList ，IDEA 会自动生成一个带 QueryWrapper 参数的方法。运行它，观察 Console 日志里打印的 SQL 是否包含 WHERE 条件——这证明 MyBatis Plus 的条件构造器已生效。整个过程，IDEA 的实时反馈，让升级不再是“改完一堆配置，祈祷能跑”，而是“改一行，验一行，稳扎稳打”。

我在实际使用中发现，最浪费时间的从来不是写代码，而是“确认代码是否按预期运行”。Cursor 给你一个可能正确的答案，IDEA 给你一条通往确定性的路径。当你在深夜调试一个 MyBatis 的 N+1 查询问题时，你想要的不是一个 AI 生成的“可能解决方案”，而是 IDEA 的 Database Console 里，那个能让你直接执行 EXPLAIN SELECT * FROM user WHERE id IN (1,2,3) 并看到 type: ALL 的红色警告。技术工具的价值，不在于它有多炫，而在于它能否在你最焦虑的时刻，给你一个确定的、可验证的、不容置疑的答案。这，就是我卸载 Cursor，重装 IDEA 的全部理由。