IDEA配置类故障排查：Lombok红波浪线、乱码与热部署

简介：这份 IntelliJ IDEA 常用配置整理面向 Java 开发者与需要长期使用 IDEA 的团队，聚焦 2020.1.4 及 2022.2 版本中界面、编码、插件、快捷键与热部署等常见设置的统一与优化，适合希望减少重复配置、提升日常开发顺手度的初中级读者参考。资源包共 1 个 docx 文档，约 1.02MB，以文字条目和配置项说明为主，结构按下载安装、插件推荐、基本设置、热部署、自定义缩写、快捷键、界面优化、配置导入导出及常见问题展开。已有 480 人学习，内容覆盖 Vuesion Theme、GitToolbox、Maven Helper、Lombok 等插件用途，也整理了文件编码、自动导包、代码提示大小写、显示空格、Unix 换行符、内存指示器、MyBatis 日志格式化和 DAO/XML 互跳等细节。读者可据此快速对照自己的 IDE 选项，形成一份可复用的配置清单，并在换机或团队协作时通过导入导出保持环境一致。

1. 一个“什么都没动”的下午：配置类故障为什么最磨人

早上拉完代码，IntelliJ IDEA 里整个项目一片红：实体类的 getter 全飘红、控制台中文变问号、改完一行 Java 代码还得手动重启服务。你没动过任何业务逻辑，昨天还好好的。这类故障最难的地方是没有堆栈——Invalidate Caches 清了、索引重建了、IDE 重启了、插件重装了，红色提示还在原地。搜索引擎给的答案往往一句“勾选 XX 就好”，可打开设置发现那个勾本来就勾着。这里把 2020.1.4 和 2022.2 两个版本上最容易出错的地方拆开讲：每一处先说报错长什么样，再说根因落在哪一层，最后给出能照抄的开关路径和验证命令。刚接手项目的人顺着路径点，被同一个红波浪线折磨过的老手可以直接跳到根因那一段。

2. 满屏红波浪线：Lombok 注解不生效的三层排查

2.1 报错长什么样，先分清是 IDE 红还是编译红

最典型的一条是Cannot resolve method 'getName' in 'User'，光标停在实体类的user.getName()上，整个类只有@Data、@Getter这类注解，没有手写方法。顺着往上看还能看到Cannot resolve symbol 'log'（@Slf4j场景），或者 mapper 接口里的xxxQueryWrapper找不到。

第二个高频现场是构建阶段：IDEA 里一切正常，mvn clean compile却报cannot find symbol，指向的正是 getter 或 builder。还有一种是反过来——命令行编译通过，IDE 一直红。

这三者指向的不是同一个问题，所以第一步不是去改设置，而是先定性：

# 在项目根目录执行，跳过测试直接编译 mvn -q clean compile

如果这条命令能过，说明问题只在 IDE 的索引层，源码和依赖都没毛病，重点是插件和缓存。如果这条命令也报cannot find symbol，那就是编译期注解处理没生效，光靠重启 IDE 永远修不好。这两个结论对应的修法完全不同，先跑这一步能省掉大量“删缓存重启”的无效操作。

另外留意一个容易误判的信号：@Data生成的equals/hashCode/toString在断点调试时能看到，但getName红着——这几乎可以确定是 IDE 侧没认注解，而不是依赖没下载下来。

2.2 根因在三层：插件、注解处理器、依赖作用域

Lombok 的工作原理决定了它必须在三个位置同时被“承认”，缺任意一层都会红。

第一层是编辑器插件。IDEA 的 Java 语法解析器不认识@Data会生成方法这件事，是 Lombok 插件在编辑器里做了增强，让飘红消失、跳转可用。插件没装或者装了但没启用（Settings -> Plugins -> Installed里是灰色），编辑器就一定是红的，跟编译能不能过无关。

第二层是注解处理器。@Data真正生成字节码靠的是 javac 的 annotation processor，开关在Settings -> Build, Execution, Deployment -> Compiler -> Annotation Processors，必须勾上Enable annotation processing。这个勾默认关闭，很多人只装了插件，编译期仍然拿不到方法。2020.2 之后的版本还多了一个隐性开关，IDEA 会跟踪注解处理器依赖，Lombok 不在跟踪列表里的时候处理器会被跳过，表现为“插件有、开关开，还是红”。

第三层是依赖作用域。pom.xml里 Lombok 通常写成provided，编译期可见、打包时不带进去，这是对的。问题出在版本上：项目里同时存在多个 Lombok 版本（比如父 pom 一个、当前模块一个、某个 starter 又传递进来一个），IDE 用的和编译用的不是同一个，就会出现一边好一边坏。

三层的关系可以用一句话概括：插件负责“看起来不红”，处理器负责“编译能过”，依赖负责“大家都用同一个版本”。出问题的时候按这个顺序往下查，比乱点设置快得多。

2.3 按顺序修：三个开关加一条 VM 参数

先确认插件和处理器，再处理依赖。

<!-- pom.xml：Lombok 用 provided，版本交给父 pom 或 dependencyManagement 统一 --> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>${lombok.version}</version> <scope>provided</scope> </dependency>

scope写provided的含义是：编译和测试阶段在 classpath 上，打包产物里不含它。写成compile也不会报错，但会把 Lombok 打进最终产物，属于典型的“能跑但不对”。版本用属性统一，别让子模块各写各的。

插件和开关按路径核对一遍：

1. Settings -> Plugins搜Lombok，确认状态是已启用，不是灰色。
2. Settings -> Build, Execution, Deployment -> Compiler -> Annotation Processors，勾选Enable annotation processing。
3. 同一页面下方如果有处理器路径配置，保持默认（交给 IDEA 自动探测）即可，手填路径反而容易指到旧版本。

针对 2020.2 之后的版本，还有一步常被漏掉：

# 编辑 idea64.exe.vmoptions（Windows）或 Help -> Edit Custom VM Options -Djps.track.ap.dependencies=false

这个参数的作用是让 IDEA 不再严格校验注解处理器的依赖完整性。文件名以jps开头说明它作用于 Java 编译进程，不是编辑器本身，所以改完必须彻底退出 IDE 再启动，靠 File 菜单里的 Restart 有时不够干净。改之前备份一下这个文件，里面通常还有其他堆大小参数。

三步做完之后不要立刻下结论，先Build -> Rebuild Project全量重建一次，让处理器真正跑一遍。只做Build Project有时只增量处理改动的文件，旧的错误状态会残留。

2.4 用 Maven Helper 看依赖树，把版本冲突揪出来

当“三层都对了还是红”时，基本可以锁定版本冲突。Maven Helper插件的价值就在这里：装完之后打开pom.xml，底部多一个Dependency Analyzer标签页，切到Conflicts，所有重复坐标会列出来，选中一条能在右侧看到完整的两条引入路径。

不想装插件也可以直接敲命令：

# 只看 lombok 这一个坐标被谁引入了，以及最终生效的版本 mvn dependency:tree -Dincludes=org.projectlombok:lombok -Dverbose # 排查更大范围的版本收敛问题 mvn dependency:tree -Dverbose -Dincludes=org.slf4j

-Dincludes的参数格式是groupId:artifactId，可以只写前半段做前缀匹配。-Dverbose会展开被省略的冲突节点，标出omitted for conflict的那一行，那就是被顶掉的版本。

修复方式是在dependencyManagement里锁死版本，而不是在每个模块里加exclusions逐个排除——后者在依赖变化时很容易漏掉。

<dependencyManagement> <dependencies> <dependency> <groupId>org.projectlombok</groupId> <artifactId>lombok</artifactId> <version>1.18.24</version> </dependency> </dependencies> </dependencyManagement>

锁定之后回到 IDEA 右侧 Maven 面板点一次刷新，让 IDE 重新拉一遍 classpath。这一步很多人忘了做，改了 pom 但 IDE 还拿着旧索引，红波浪线自然不消。

最后验证：随便找一个用了@Data的类，Ctrl点进 getter 调用处，能跳到字段上而不是提示找不到，同时mvn clean compile通过，两个都满足才算真的修好了。

3. 中文变问号、整个文件变红：编码与换行符的两类“假故障”

3.1 三类乱码，对应三层不同的配置

乱码最坑的地方是看起来都是“编码问题”，实际改的位置完全不一样。

第一类是控制台输出乱码。代码里System.out.println("测试")，运行起来打印一堆问号或者方块。这类问题的根源在 JVM 的默认字符集和终端编码不一致，改源文件编码没用。

第二类是打开别人的源文件是乱码。整个文件的中文变成锟斤拷或者一堆生僻字。这是文件本身用 GBK 存的，IDE 按 UTF-8 去解。2020.1.4 版本打开这类文件时，右下角会显示当前识别的编码，点一下可以Reload in another encoding，试 GBK 一般就对了。但重载只是临时看一下，文件没转码，下次打开还是乱码。

第三类是 properties 文件里的中文变成\u4e2d\u6587这种转义，或者反过来，本来是转义的结果显示成了乱码。properties 有独立的编码设置项，跟全局编码是分开的。

三类现象对应三个位置，混着改只会越改越乱。我一般的顺序是：先确认源文件本身是什么编码，再统一工程编码，最后才动运行参数。

3.2 File Encodings 里那三个下拉框各管什么

Settings -> Editor -> File Encodings打开后有三个主要下拉框，很多人只改第一个，结果问题依旧。

第三项那个勾选框值得单独说。勾上之后，IDE 在编辑时把\u4e2d显示成“中”，保存时再转回转义序列，读起来舒服且不影响运行时行为。不勾的话，你在 properties 里直接写中文，某些读取方式会拿到乱码。

还有一个容易忽略的开关在同一个页面下方：Create UTF-8 files，控制新建文件时用哪种编码，选with NO BOM。BOM 这个东西在 Windows 记事本里很常见，带 BOM 的 UTF-8 文件被某些解析器读到会在开头多出不可见字符，报错信息往往莫名其妙。

老项目迁移时不要一次性全改。正确做法是先把Project Encoding保持不变，用Reload in another encoding逐个确认文件真实编码，转码保存之后再统一设置。直接改全局设置再全量保存，等于把一批本来能读的文件写坏。

3.3 一个换行符，让整个文件变成 diff

这个坑比乱码更隐蔽，因为它不报错，只是让代码评审变得没法看。

现象是：你只改了一行逻辑，git diff显示整个文件从头到尾都是修改。提交上去之后，同事拉下来再改一行，又整个文件变红。来回几次，文件的真实变更历史就彻底找不回来了。

原因是换行符。Windows 上默认CRLF（\r\n），Linux 和 macOS 上是LF（\n）。文件在两种环境之间流转时，如果 git 的core.autocrlf配置和 IDE 的行分隔符设置对不上，就会出现“看着没改，实际每个字节都变了”。

先在 IDE 里统一：Settings -> Editor -> Code Style -> Line separator，选Unix and macOS (\n)。这个设置影响新建文件和格式化时的输出。已经存在的文件，右下角状态栏会显示当前是CRLF还是LF，点一下可以转换，转换后记得保存。

再在仓库层面兜底，项目根目录加一个.gitattributes：

# .gitattributes：强制仓库内统一用 LF，检出时按平台处理 * text=auto eol=lf # 二进制文件不要做换行符转换，否则会损坏 *.png binary *.jpg binary *.jar binary *.woff binary

text=auto让 git 自动判断哪些是文本文件，eol=lf表示仓库里统一存 LF。binary那几行是必须的，图片、jar 包一旦被当成文本做转换，文件头就废了，编译时报的错和换行符毫无关系，排查起来极其费劲。

加完.gitattributes之后，已有文件不会自动修正，需要重新规范化一次：

# 清理索引缓存后重新检出，让 .gitattributes 生效 git add --renormalize . git status

--renormalize的作用是按新的属性规则重新计算所有已跟踪文件，只影响行尾，不改内容。执行完git status会显示一批文件被修改，这时候的 diff 才是真实的换行符变更，提交一次之后就稳定了。注意这一步要在没有未提交业务改动的时候做，否则混在一起很难区分。

3.4 改完怎么验证

编码和换行符都属于“改了不知道有没有生效”的配置，随手验一下能省掉后面的反复。

新建一个 Java 类，在类里写一行中文注释和一句System.out.println("中文测试")，看三处：编辑器里注释是否正常显示、右下角编码是否显示 UTF-8、运行后控制台输出是否是中文而不是问号。控制台仍然乱码的话，问题就在运行参数上，需要给运行配置加 VM 参数：

# 在 Run/Debug Configurations -> VM options 里加 -Dfile.encoding=UTF-8

这个参数告诉 JVM 用 UTF-8 作为默认字符集，影响new String(bytes)这类依赖默认编码的调用。加在运行配置里只对当前配置生效，需要全局生效就写进idea64.exe.vmoptions。改完必须重启进程，热部署不会让字符集参数生效。

换行符的验证更简单：新建文件看状态栏是不是LF，然后随便改一行提交，git diff --stat看变更行数是不是 1 行。如果显示几百行，说明前面的规范化没做干净。

4. 改一行代码要重启一次：热部署开关的完整链条

4.1 现象：热部署“配了”，但每次还是重启

配过热部署的项目，最常见的抱怨是“照着教程配完，改代码还是要重启”。表现有好几种：改了模板文件刷新浏览器没变化；改了 Java 方法体，日志里没有任何 reload 记录；改了配置类，服务直接报错退出。

这里的判断标准很明确：改完之后看控制台有没有出现类加载器重启的日志。有日志说明热部署在工作，只是没覆盖到你改的那部分；没有日志说明整条链路某一环断了。

还有一个容易误判的情况：改的是方法签名（加参数、改返回值类型），这种情况本来就不支持热替换，任何方案都会触发重启。先排除这一类，再去查配置。

4.2 三个开关缺一不可：自动编译、Registry、运行方式

热部署能生效的前提是“类文件被重新编译了”。IDEA 默认不会在你保存文件时自动编译，它只在 Run 或 Build 的时候编译。所以第一层是自动编译开关：Settings -> Build, Execution, Deployment -> Compiler，勾选Build project automatically。

第二层是 Registry 里的一个隐藏开关。2020.1.4 和 2022.2 都能通过Ctrl + Shift + Alt + /打开 Registry（新版入口叫Registry...），找到compiler.automake.allow.when.app.running，勾上。这个开关的含义是：应用正在运行时也允许自动编译。不勾的话，程序跑起来之后自动编译会被挂起，改了代码等于没改。

第三层是运行方式。如果用java -jar或者外部脚本启动，IDEA 的编译结果根本不会进到运行中的进程里，前面两个开关配了也白配。必须用 IDEA 自己的运行配置启动，或者依赖 devtools 这类在应用内部监听 classpath 变化的机制。

三层的关系是递进的：自动编译负责“产生新的 class 文件”，Registry 开关负责“运行中也产生”，devtools 负责“产生之后让应用感知到”。少任何一环，链条就断。

4.3 从零配一遍，带上验证点

先加依赖：

<!-- 只用于开发期，打包时不带进产物 --> <dependency> <groupId>org.springframework.boot</groupId> <artifactId>spring-boot-devtools</artifactId> <optional>true</optional> <scope>runtime</scope> </dependency>

optional写true表示这个依赖不传递给下游模块，避免被打进其他服务的依赖树。scope用runtime是因为编译期不需要它的类，只在运行时参与类加载。

然后按顺序操作：

1. 勾选Build project automatically。
2. Ctrl + Shift + Alt + /打开 Registry，勾选compiler.automake.allow.when.app.running。
3. 用 IDEA 的运行配置启动应用，不要用命令行。
4. 改一个 Controller 方法里的字符串，等 2 到 3 秒，看控制台是否出现重启日志。

第 4 步的等待时间很重要。自动编译有防抖延迟，改完立刻刷新页面往往看不到变化，等两秒再试。这一步也解释了为什么很多人说“热部署时灵时不灵”——不是不灵，是没等编译完成。

devtools 还有一个默认行为要留意：它会把META-INF/resources、resources、static、public、templates这些目录排除在重启范围外，改这些目录下的文件触发的是“只刷新静态资源、不重启类加载器”。如果改了模板没生效，先确认模板是不是放在这几个目录里，放对了的话需要手动触发一次完整重启来验证配置本身有没有问题。

想确认 devtools 到底有没有接管，可以在启动日志里找LiveReload server is running on port 35729这类字样。端口是 35729 说明 LiveReload 起来了，浏览器装了对应插件的话还能自动刷新。没有这行日志，说明依赖没生效或者被排除了。

4.4 内存不够时的表现，和右下角那个数字

热部署配好之后，另一个问题会浮出来：频繁编译导致堆内存吃紧，IDE 开始卡、索引变慢、代码提示延迟一两秒才出来。

这类现象容易被归因到“机器不行”，实际是默认堆上限偏小。打开内存指示器的方式是双击Shift搜索Show Memory Indicator，把开关置为 ON，右下角就会出现一个数字，形如512M of 2048M。前面是当前已用，后面是上限。

观察一段时间，如果已用长期贴着上限，GC 频繁，就该调大：

# idea64.exe.vmoptions 里的两个关键参数 -Xms1024m -Xmx4096m

-Xms是初始堆，-Xmx是最大堆。建议把这两个值设成一样，避免运行过程中反复扩容带来的停顿。数值不是越大越好，超过物理内存的 1/4 之后，系统层面的换页反而会让 IDE 更卡。改完必须完全退出 IDE 再启动，用 Restart 有时不重新读这个文件。

还有一个跟内存相关的坑：开启自动编译之后，每次保存都会触发一次增量编译，大项目里 CPU 和内存占用会明显上升。如果只是想解决热部署，把自动编译限制在必要的时候，比一味加内存划算。

验证热部署是否真的生效，我习惯用这一组动作：改一个返回字符串的接口方法，等 3 秒，看控制台重启日志，然后curl一下接口看返回是否变了。三个信号都有了，才算配置到位。

5. 常见问题避坑：五个改完配置反而更糟的瞬间

5.1.iml和.idea被提交进仓库，同事拉下来全是冲突

现象：git status里常年挂着一堆.idea/下的文件，改个主题、换个 JDK 都会产生变更；合并分支时这些文件十有八九冲突，解决冲突的方式通常是随便选一边，然后某人的运行配置就没了。

原因是.iml和.idea目录存的是本机相关的工程元数据——模块依赖、SDK 名称、运行配置、代码风格。这些东西因机器而异，本来就不该进版本库。有些项目模板没配.gitignore，或者有人用git add .一把梭提交了一次，后面就跟着一直脏。

解决分两步。先加忽略规则：

# .gitignore 里加上这几行 .idea/ *.iml *.ipr *.iws out/ target/

如果这些文件已经被跟踪了，只加.gitignore是不起作用的，必须先取消跟踪：

# 从索引里移除但保留本地文件，避免误删 git rm -r --cached .idea git rm --cached *.iml git commit -m "chore: 移除 IDE 元数据文件的版本跟踪"

--cached这个参数是关键，它只动索引不动磁盘，本地配置不会丢。团队里每个人都执行一次这个提交之后，各自的 IDE 配置才真正独立。顺带提一句，2022.2 版本把不少原本存在.idea里的配置迁到了别的位置，跨版本导入时容易出问题，这更说明这些文件不该共享。

5.2 代码提示忽略大小写没配对，反而搜不到类

现象：Ctrl + N搜类名，输入小写的usercontroller搜不到UserController；或者反过来，输入UC想按驼峰匹配，结果提示列表里塞满了不相关的类。

原因在Settings -> Editor -> General -> Code Completion里的Match case开关。这个开关的含义是“匹配时是否区分大小写”。勾上之后，输入小写就只匹配小写开头的类；不勾则忽略大小写，输入什么都行。问题在于这个开关的语义和直觉相反，很多人以为“勾上就是忽略”，实际勾上就是严格匹配。

至于驼峰匹配（输入UC命中UserController），那是另一个独立能力，由Match case之外的机制控制，两个一起调才能得到想要的效果。我一般的配法是：Match case不勾，让大小写不敏感；驼峰匹配保持默认开启。

改完之后不用重启，但已经打开的搜索窗口要关掉重开，缓存里的索引结果不会自动刷新。验证方式是搜一个确定存在的类，分别用小写全拼和驼峰首字母试一次，两种都能命中就对了。

还有一个相关设置在同一页下方：Show the parameter info popup，控制输入方法名后自动弹参数提示。这个提示在大项目里会有几百毫秒延迟，觉得卡可以关掉，需要时手动按Ctrl + P调出来。

5.3 MyBatis 日志只有问号，SQL 参数看不见

现象：控制台打印出Preparing: select id, name from user where id = ?，下一行是Parameters: 1001(Integer)，两行分开。想把完整的 SQL 拿去数据库里跑一遍复现问题，还得手动拼参数，遇到日期和字符串类型更容易拼错。

原因是 MyBatis 内部用的是PreparedStatement，日志天然分两行输出：一行是带占位符的模板，一行是参数值。这是 JDBC 层面的行为，不是配置错了。想看到拼好的完整 SQL，得靠日志实现或者插件做二次加工。

第一种做法是换日志实现：

# application.yml 里指定 MyBatis 使用的日志实现 mybatis: configuration: log-impl: org.apache.ibatis.logging.stdout.StdOutImpl

log-impl的可选值有SLF4J、LOG4J2、STDOUT等。设成STDOUT会直接把 SQL 打到控制台，格式比日志框架更紧凑，但会绕过日志级别控制，生产环境不要用。

第二种做法是装格式化插件，把两行合并成一行可执行 SQL。这类插件读取的是 MyBatis 输出的日志文本，所以前提是日志级别打开了：mapper 包下的日志级别要是DEBUG。级别没开，插件再装也抓不到内容。

我一般两个一起用：开发期开STDOUT加插件，看拼好的 SQL 直接粘到客户端执行；提交前把log-impl去掉，交回日志框架控制。

5.4 列模式快捷键和系统快捷键冲突，按了没反应

现象：照着教程按Alt + 左键拖动想进列编辑模式，结果触发的是窗口拖动或者什么都没发生；Shift + Alt + 左键也不灵。

原因分两种。一种是系统或其他软件占用了这组组合键，比如某些显卡驱动、截图工具、输入法会把Alt + 鼠标注册成自己的热键。另一种是 IDE 里这个动作被重新绑定了，Settings -> Keymap搜Add or Remove Caret能看到当前绑定。

确认方式很直接：在Keymap里搜对应动作，看右侧显示的快捷键是什么，右键可以Add Keyboard Shortcut或Add Mouse Shortcut重新绑。如果系统层面被占用，换一组组合键比关掉别的软件更省事。

列编辑的两个模式区别也值得记一下：标准列模式要求每行在同一列位置操作，适合批量加前缀；不规则列模式可以在不同位置各加一个光标，适合改几个分散的变量名。前者是Alt + 拖动，后者是Shift + Alt + 点击。搞清楚哪个是哪个，比反复试快捷键快。

顺带说一个相关的：Ctrl加左键在类名或方法名上按住，2020.1.4 之后默认弹出的菜单包含“跳实现”“跳接口”“跳返回值类型”几个选项。这套行为可以通过Quick Lists自定义，把自己常用的跳转组合成一个列表再绑快捷键。老项目里接口和实现类数量多的时候，这个列表能省掉大量来回切换。

5.5 导出配置再导入，新版本文案全变

现象：在 2020.1.4 上File -> Export Settings导出一份配置，换到 2022.2 上File -> Import Settings导入，界面主题变了、快捷键对不上、插件列表里一堆装不上的旧版本。

原因是导出的配置文件里包含了版本相关的元数据，插件那一项记录的是具体版本号。跨大版本导入时，IDEA 会尝试安装旧版本插件，装不上就跳过，表现就是“导了但没完全导”。

更稳妥的做法是只导出真正需要同步的部分。导出对话框里可以勾选具体类别，把Keymaps、Code Style、Live Templates勾上，把Plugins和UI Settings取消。前几项是纯配置，跨版本兼容性好；后两项跟版本强相关，导过去大概率出问题。

插件列表建议单独维护成一份文本清单，换机器时照着搜一遍重装。版本对不上的插件在新版本里往往有替代品，硬导旧配置反而会引入一堆莫名其妙的兼容问题。

导入之后至少验证三处：快捷键里自己改过的那几个还在不在、代码风格里缩进是不是 4 个空格、Live Templates 里自定义的缩写（比如把System.out.println()缩成syso）能不能展开。这三处是日常使用频率最高、出问题最容易被察觉的地方。

6. 十分钟定性：先分清是环境问题还是代码问题

排查这类故障，最耗时间的不是修，是判断方向。方向错了，删缓存、重装 IDE、换 JDK 版本，一晚上就没了。我自己总结的一个判断表，遇到红波浪线或者“改了没反应”先对一遍：

用这张表的时候有个细节：先做“能编译吗”这一步，再往下分流。这一步只花十几秒，却能砍掉一半的排查路径。我见过太多人一上来就清缓存重建索引，索引重建一次要几分钟，重建完问题还在，时间全浪费在这上面。

第二个习惯是看日志而不是看界面。热部署有没有生效、注解处理器有没有跑、依赖最终用的是哪个版本，这些都有日志或命令输出可以确认。界面上的红色提示只是结果，不是证据。

第三个习惯是改配置前先记下原值。idea64.exe.vmoptions里的堆参数、Code Style里的缩进、Keymap里的绑定，改动之前截图或者复制一份，出问题时能快速回退。配置类故障最怕的就是“改了五个地方，不知道哪个改坏了”。

从那以后我每次换机器、接手新项目，都强制自己先把这几条走一遍：编译能不能过、注解处理开没开、编码和换行符统不统一、热部署三个开关是否齐全。走完再动业务代码，能省掉后面大量的“明明没改什么怎么就红了”。希望帮到你。

本文还有配套的精品资源，点击获取