简介这份 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 logSlf4j场景或者 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.xmlLombok 用 provided版本交给父 pom 或 dependencyManagement 统一 -- dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId version${lombok.version}/version scopeprovided/scope /dependencyscope写provided的含义是编译和测试阶段在 classpath 上打包产物里不含它。写成compile也不会报错但会把 Lombok 打进最终产物属于典型的“能跑但不对”。版本用属性统一别让子模块各写各的。插件和开关按路径核对一遍Settings - Plugins搜Lombok确认状态是已启用不是灰色。Settings - Build, Execution, Deployment - Compiler - Annotation Processors勾选Enable annotation processing。同一页面下方如果有处理器路径配置保持默认交给 IDEA 自动探测即可手填路径反而容易指到旧版本。针对 2020.2 之后的版本还有一步常被漏掉# 编辑 idea64.exe.vmoptionsWindows或 Help - Edit Custom VM Options -Djps.track.ap.dependenciesfalse这个参数的作用是让 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 -Dincludesorg.projectlombok:lombok -Dverbose # 排查更大范围的版本收敛问题 mvn dependency:tree -Dverbose -Dincludesorg.slf4j-Dincludes的参数格式是groupId:artifactId可以只写前半段做前缀匹配。-Dverbose会展开被省略的冲突节点标出omitted for conflict的那一行那就是被顶掉的版本。修复方式是在dependencyManagement里锁死版本而不是在每个模块里加exclusions逐个排除——后者在依赖变化时很容易漏掉。dependencyManagement dependencies dependency groupIdorg.projectlombok/groupId artifactIdlombok/artifactId version1.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打开后有三个主要下拉框很多人只改第一个结果问题依旧。配置项作用范围建议值常见误配Global EncodingIDE 全局默认新建文件的初始编码UTF-8留成 GBK新建类里写中文就炸Project Encoding当前工程内文件的默认编码UTF-8老项目是 GBK直接改成 UTF-8 导致全红Default encoding for properties files.properties专用UTF-8 并勾选Transparent native-to-ascii conversion只改前两项properties 里中文仍是转义第三项那个勾选框值得单独说。勾上之后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\nLinux 和 macOS 上是LF\n。文件在两种环境之间流转时如果 git 的core.autocrlf配置和 IDE 的行分隔符设置对不上就会出现“看着没改实际每个字节都变了”。先在 IDE 里统一Settings - Editor - Code Style - Line separator选Unix and macOS (\n)。这个设置影响新建文件和格式化时的输出。已经存在的文件右下角状态栏会显示当前是CRLF还是LF点一下可以转换转换后记得保存。再在仓库层面兜底项目根目录加一个.gitattributes# .gitattributes强制仓库内统一用 LF检出时按平台处理 * textauto eollf # 二进制文件不要做换行符转换否则会损坏 *.png binary *.jpg binary *.jar binary *.woff binarytextauto让 git 自动判断哪些是文本文件eollf表示仓库里统一存 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.encodingUTF-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 groupIdorg.springframework.boot/groupId artifactIdspring-boot-devtools/artifactId optionaltrue/optional scoperuntime/scope /dependencyoptional写true表示这个依赖不传递给下游模块避免被打进其他服务的依赖树。scope用runtime是因为编译期不需要它的类只在运行时参与类加载。然后按顺序操作勾选Build project automatically。Ctrl Shift Alt /打开 Registry勾选compiler.automake.allow.when.app.running。用 IDEA 的运行配置启动应用不要用命令行。改一个 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.StdOutImpllog-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 版本一晚上就没了。我自己总结的一个判断表遇到红波浪线或者“改了没反应”先对一遍报错特征大概率归属第一步验证动作只有 IDE 飘红命令行能编译IDE 索引层mvn -q clean compile通过则查索引和插件IDE 和命令行都报cannot find symbol编译期注解处理查Enable annotation processing和处理器依赖编译通过运行时报NoSuchMethodError依赖版本冲突mvn dependency:tree -Dverbose找被顶掉的版本控制台中文乱码文件本身正常JVM 字符集运行配置加-Dfile.encodingUTF-8打开文件一片乱码文件真实编码右下角状态栏切换编码重新加载改一行代码整个文件变 diff换行符状态栏看 CRLF/LF检查.gitattributes改代码后必须重启自动编译链路看控制台有无 reload 日志逐个查三个开关改了模板没生效静态资源排除规则手动触发完整重启确认配置本身没问题用这张表的时候有个细节先做“能编译吗”这一步再往下分流。这一步只花十几秒却能砍掉一半的排查路径。我见过太多人一上来就清缓存重建索引索引重建一次要几分钟重建完问题还在时间全浪费在这上面。第二个习惯是看日志而不是看界面。热部署有没有生效、注解处理器有没有跑、依赖最终用的是哪个版本这些都有日志或命令输出可以确认。界面上的红色提示只是结果不是证据。第三个习惯是改配置前先记下原值。idea64.exe.vmoptions里的堆参数、Code Style里的缩进、Keymap里的绑定改动之前截图或者复制一份出问题时能快速回退。配置类故障最怕的就是“改了五个地方不知道哪个改坏了”。从那以后我每次换机器、接手新项目都强制自己先把这几条走一遍编译能不能过、注解处理开没开、编码和换行符统不统一、热部署三个开关是否齐全。走完再动业务代码能省掉后面大量的“明明没改什么怎么就红了”。希望帮到你。本文还有配套的精品资源点击获取