
简介这是一份面向Java开发者的IntelliJ IDEA常用配置整理兼容2020.1.4与2022.2版本重点解决开发环境个性化设置繁琐、团队配置不同步以及常用效率技巧分散等问题。压缩包仅含1个docx文档大小约1.02MB便于快速查阅与按需检索。内容覆盖插件选择、编码与字体、自动导包、代码提示、自动编译、热部署、自定义缩写、快捷键、界面优化和配置导入导出并补充常见警告处理插件部分涉及主题、Git工具、Maven依赖分析、控制台着色、Lombok、代码缩略图、编码规范及MyBatis日志与跳转等还给出列模式编辑、快速访问列表等操作示例读者可据此搭建更顺手的开发环境、减少重复设置并同步多台机器配置。目前已有481人学习适合希望系统梳理IDEA配置、提升日常编码效率或需要统一开发环境、沉淀个人配置方案的初中级Java开发者参考。1. 从一份把 2022.2 拦在启动界面外的 vmoptions 说起把老机器上用了两年的 2020.1.4 配置往新装的 2022.2 上搬双击图标启动画面闪一下就没影了。翻日志才发现一行Unrecognized VM option UseConcMarkSweepGC——那是当年从某篇帖子抄进idea64.exe.vmoptions的参数在 2022.2 内置的 JBR 17 上直接变成致命伤。类似问题不只一处。这套 IDEA 常用配置真正麻烦的地方在于2020.1.4 和 2022.2 的目录命名、JVM 基线、插件兼容规则、索引机制都不一样整包复制必翻车什么都不搬又回到裸机重配。下面按启动参数、编辑器规则、插件清单、索引策略四块拆开每一块都落到「改哪个文件的哪一行、改完怎么验证」。适合手里同时维护两套 IDE 的人。2. 配置到底存在哪把 config、plugins、system 三个目录分开看2.1 三个目录各管什么哪些能带走哪些不能IDEA 把「你主动改的东西」和「它自己算出来的东西」分开放。前者在config 目录里全是 XML 和 properties可读可提交后者在system 目录里是索引、缓存、日志、本地历史动辄几百 MB 且和绝对路径强绑定。判断标准只有一句删掉之后还能靠重新点一遍设置恢复的属于 config删掉之后 IDE 要重新算一遍的属于 system。前者能备份能搬后者永远不搬。config 目录里值得记住的几项路径相对 config内容换版本可否直接复制options/*.xml全局设置如editor.xml、ide.general.xml、other.xml、keymap.xml谨慎部分项含版本私有字段codestyles/*.xml代码风格方案可inspection/*.xml检查方案可但新版新增的检查项不会自动出现templates/*.xml自定义 live template 组可keymaps/*.xml自定义快捷键方案可新版新增动作不会自动绑定plugins/已安装插件按需不要整包搬idea64.exe.vmoptions自定义启动参数必须逐行检查idea.properties自定义路径等属性可注意里面写的绝对路径log/caches/index/LocalHistory/日志、索引、本地历史永不搬system 目录才是真正的黑匣子删了不影响设置但下次启动要重建索引大项目能卡十几分钟。注意window.state.xml、recentProjects.xml这类记录窗口尺寸和最近项目的文件别跨机器复制。分辨率不同会得到一堆定位诡异的浮动窗口还夹着一堆本机不存在的项目路径。2.2 2020.1.4 与 2022.2 的目录名与路径差异两个版本在磁盘上是并列存在的目录名带版本号互不干扰——这正是能同时装两版、分别配置的基础。系统2020.1.4 配置目录2022.2 配置目录Windows%APPDATA%\JetBrains\IntelliJIdea2020.1%APPDATA%\JetBrains\IntelliJIdea2022.2macOS~/Library/Application Support/JetBrains/IntelliJIdea2020.1~/Library/Application Support/JetBrains/IntelliJIdea2022.2Linux~/.config/JetBrains/IntelliJIdea2020.1~/.config/JetBrains/IntelliJIdea2022.2system 目录在 Windows 上是%LOCALAPPDATA%\JetBrains\同名macOS 是~/Library/Caches/JetBrains/同名Linux 是~/.cache/JetBrains/同名。这里有个高频误会社区版的目录前缀不是IntelliJIdea而是IdeaIC比如IdeaIC2022.2。把旗舰版的配置往社区版目录里倒结果就是「明明复制过去了打开还是默认设置」。不想背路径用 IDE 自己给的入口确认最稳Help → Edit Custom VM Options打开的文件就在 config 根目录在编辑器标签上右键Copy Path即可Help → Show Log in Explorer / Finder定位到的是 system 目录下的log/。两个入口各摸一次两个根目录就都拿到了。2.3 用 idea.properties 把配置挪到一块固定盘默认路径跟着用户目录走重装系统或换机器就散架。把配置集中到D:\ide-config\idea2022.2这种固定位置备份和版本管理都省事。做法是在idea.properties里写路径# 配置文件目录放设置、插件、自定义 vmoptions idea.config.pathD:/ide-config/idea2022.2/config # 索引与缓存建议放在 SSD 上可以随时整个删掉 idea.system.pathD:/ide-config/idea2022.2/system # 插件单独一个目录方便按版本切 idea.plugins.pathD:/ide-config/idea2022.2/plugins # 日志位置 idea.log.pathD:/ide-config/idea2022.2/log # 大文件智能提示上限KB超过就不做语法分析 idea.max.intellisense.filesize5000参数说明四个路径参数必须用正斜杠/Windows 下反斜杠会被当转义idea.system.path和idea.config.path千万别指向同一个目录否则清理缓存时容易连设置一起带走idea.max.intellisense.filesize默认 2500KB调大能救超大生成文件的高亮代价是内存和索引时间上升5000 是个平衡点。注意Help → Edit Custom Properties生成的文件本身就位于 config 目录用它去改idea.config.path属于自指不生效。要改这个路径得动安装目录下bin/idea.properties或者设环境变量IDEA_PROPERTIES指向你自己的 properties 文件后者更适合两版共用一份路径约定。3. 内存与启动参数一份能同时喂给两个版本的 vmoptions3.1 堆、Metaspace、CodeCache 三个数字怎么定JVM 参数里真正影响体感的就三个数-Xmx堆上限、-XX:MaxMetaspaceSize类元数据、-XX:ReservedCodeCacheSizeJIT 编译后的代码缓存。-Xmx是最容易被玄学化的一项。两个版本的出厂默认值不在一个量级2020.1.4 那份通常在几百 MB2022.2 已经到 2GB 附近直接照抄别人的数字最容易出问题。给一个可落地的判定法看项目规模不看机器内存。中小项目 2048m 够用多模块、开启大量检查、同时开三四个窗口的3072m 是常见起点机器总内存 16GB 以上再考虑 4096m 及以上超过物理内存一半基本是浪费因为 IDE 的瓶颈往往在索引 IO 而不是堆。CodeCache 的问题是另一种不够用时日志里会出现CodeCache is full. Compiler has been disabled之后 IDE 响应变慢但不报错很隐蔽。默认 240m 对装了十几个插件、开着 Kotlin 和大型 Java 项目的环境偏紧512m 是安全值。Metaspace 默认无上限但配了-XX:MaxMetaspaceSize后内存曲线可控768m 对大多数场景足够。3.2 文件在哪安装目录 bin 与 config 目录的区别.vmoptions有两份含义完全不同安装目录/bin/idea64.exe.vmoptions出厂默认值升级时会被覆盖不要改这里config 目录/idea64.exe.vmoptions用户自定义优先级更高Help → Edit Custom VM Options第一次点击时会自动从默认文件复制一份出来。血泪经验就一句改错文件等于没改。很多人改完重启发现参数没生效八成是改了安装目录那份或者改的是idea.exe.vmoptions32 位新版根本不读。环境变量IDEA_VM_OPTIONS可以指定任意路径的 vmoptions 文件两版共用一份配置时很有用。但共用有前提2020.1.4 跑在 JBR 11 上2022.2 跑在 JBR 17 上JDK 14 之后 CMS 收集器被移除任何-XX:UseConcMarkSweepGC、-XX:CMSClassUnloadingEnabled、-XX:UseParNewGC都会让新版直接拒绝启动。共用文件里只能保留两代 JVM 都认的参数。3.3 一份两版通用的 idea64.exe.vmoptions 模板# 起始堆与最大堆设成一致减少运行期扩堆抖动小内存机器把 -Xms 降到 256m -Xms512m -Xmx3072m # 代码缓存出现 CodeCache is full 就往上加 -XX:ReservedCodeCacheSize512m # 元数据上限装了十几个插件时建议显式给值 -XX:MaxMetaspaceSize768m # G1 在 JBR 11 和 JBR 17 上都可用2022.2 里它本来就是默认 -XX:UseG1GC -XX:SoftRefLRUPolicyMSPerMB50 -XX:CICompilerCount2 # OOM 时导出堆快照方便事后定位 -XX:HeapDumpOnOutOfMemoryError # 保留完整异常栈避免重复异常被合并后看不到根因 -XX:-OmitStackTraceInFastThrow # 仅在控制台中文乱码时启用2022.2 默认就是 UTF-8加了也无害 -Dfile.encodingUTF-8逐项说明-XX:SoftRefLRUPolicyMSPerMB50缩短软引用存活时间让 IDE 在内存紧张时更早回收缓存对象是官方模板里长期存在的一项-XX:CICompilerCount2限制 JIT 编译线程数老模板为多核机器准备保留无明显副作用-XX:-OmitStackTraceInFastThrow是排查线上问题时的后悔药——没有它重复抛出的异常栈会被 JVM 优化成空栈只剩一行NullPointerException根本没法定位。改完怎么验证不要只看「能启动」。打开Help → About或Help → Edit Custom VM Options确认文件路径指向 config 目录再在Help → Diagnostic Tools → Show Log里搜-Xmx能看到实际生效的启动命令。更直接的办法是用安装目录下的idea.bat从命令行前台启动JVM 参数错误会当场打印到终端——这比盯着启动画面猜快十倍。4. 让编辑器行为跟着仓库走code style、editorconfig 与 live template 的落地写法4.1 先关掉那些「因机器而异」的编辑器开关团队里格式化结果不一致一半原因不在 code style而在几个默认开启的编辑器开关。逐项过一遍位置在Settings → Editor → GeneralStrip trailing spaces on Save建议改成Modified Lines。选 All 会把整个文件的尾随空格清掉一个只改了三行的提交变成三百行 diff评审时非常难受。Ensure line feed at file end on Save建议开启配合.editorconfig的insert_final_newline。Change font size with CtrlMouse Wheel关掉避免误触后字号变了找不到原因。Settings → Editor → General → Auto Import里两个勾要打开Add unambiguous imports on the fly和Optimize imports on the fly这是减少手动CtrlAltO的关键。Settings → Editor → Code Completion里的Match case取消勾选否则小写开头永远匹配不到大写类名很多人以为是索引坏了。2022.2 的设置树比 2020.1.4 多了一层Advanced Settings部分原本在General下的项被挪了进去。找设置项别翻树直接在设置窗口左上角搜索框敲关键字两版都适用。Settings → Editor → File Encodings里三个下拉统一 UTF-8Global Encoding、Project Encoding、Default encoding for properties files。properties 那一项下面的Transparent native-to-ascii conversion要不要勾取决于仓库现状——勾上之后文件里的中文会以\uXXXX形式存储如果仓库里已有的是明文 UTF-8勾选会让整个文件重写一遍。团队内必须统一否则每次提交都在打架。4.2 .editorconfig 写公共规则codestyles 补 IDEA 私有规则.editorconfig是唯一一个不依赖 IDE 版本、连其他编辑器也认的载体优先级高于 IDE 内的 code style 方案。放在仓库根目录root true # 所有文件的基础约定 [*] charset utf-8 end_of_line lf insert_final_newline true trim_trailing_whitespace true indent_style space indent_size 4 # 配置类文件用 2 空格 [*.{yml,yaml,json,xml}] indent_size 2 # Java 专属禁用星号导入固定导入顺序 [*.java] ij_java_class_count_to_use_import_on_demand 999 ij_java_names_count_to_use_import_on_demand 999 ij_java_imports_layout *, |, javax.**, java.**, |, $* ij_java_blank_lines_before_package 0逻辑说明root true阻止向上级目录继续查找放在仓库根才有效前四行是所有编辑器的公共约定ij_前缀的键是 IDEA 私有扩展2020.1.4 和 2022.2 都认这一套。class_count_to_use_import_on_demand设成 999 等价于关闭「超过 N 个类就用*导入」避免不同人阈值不同导致导入语句反复变动。ij_java_imports_layout的值和 IDE 里Code Style → Java → Imports → Import Layout输入框是同一套语法|表示空行分组$*表示静态导入可以直接把 IDE 里调好的字符串粘过来。IDE 侧的 code style 方案适合放在项目里提交。让它生效的做法是在Settings → Editor → Code Style顶部把 Scheme 从Default切成ProjectIDEA 会在.idea/codeStyles/下生成两个文件!-- .idea/codeStyles/codeStyleConfig.xml -- component nameProjectCodeStyleConfiguration state option nameUSE_PER_PROJECT_SETTINGS valuetrue / /state /componentcodeStyleConfig.xml只是个开关真正的内容在同目录的Project.xml里。这两个文件不要手写让 IDE 生成后直接提交——手写容易漏字段加载失败时 IDEA 会静默回退到 Default表现为「配置明明提交了同事拉下来没生效」。检查方案同理Settings → Editor → Inspections顶部 Scheme 下拉旁的齿轮里有复制到项目级的入口落盘在.idea/inspectionProfiles/下。这里有个版本边界要说清楚2020.1.4 里叫某个名字的检查项在 2022.2 里可能被拆分或改名跨版本复制 inspection XML 不会报错但会丢掉几条规则。判断方法是切换方案后看列表里是否有灰色、带感叹号的条目。.idea/目录的提交策略建议统一成下面这张表文件/目录是否提交理由codeStyles/提交格式化一致性inspectionProfiles/提交检查规则一致compiler.xml提交编译输出配置encodings.xml提交编码约定misc.xml视情况含本机 JDK 名称多人环境易冲突workspace.xml不提交个人窗口状态、最近文件shelf/不提交个人暂存的改动4.3 live template 与 inspection 的版本无关维护方式live template 存在config/templates/*.xml里每个自定义组一个文件结构是固定的templateSet groupteamLog template namelogd valueif (log.isDebugEnabled()) {#10; log.debug(quot;$MSG$quot;, $ARG$);#10;} description带开关判断的 debug 日志 toReformattrue toShortenFQNamestrue variable nameMSG expression defaultValuequot;quot; alwaysStopAttrue / variable nameARG expression defaultValuequot;quot; alwaysStopAttrue / context option nameJAVA_STATEMENT valuetrue / /context /template /templateSet说明group是模板组名会直接显示在Insert Live TemplateCtrlJ的列表里value里的#10;是换行、quot;是引号XML 里不能直接写裸引号context决定模板在什么位置可用JAVA_STATEMENT表示语句块内。这段 XML 在 2020.1.4 和 2022.2 上结构完全一致是整个配置体系里迁移成本最低的一块。维护方式建议放弃「靠 UI 导出导入」直接把templates目录纳入版本管理改完模板后把对应 XML 提交。想更省事可以用File → Manage IDE Settings → Settings Repository指向一个自建 Git 仓库让 IDE 自己做双向同步——注意这个功能是整份配置同步冲突时以最后一次覆盖为准团队协作场景下只适合个人多机同步不适合多人共用。5. 迁移翻车记录五个从 2020.1.4 搬到 2022.2 的坑5.1 现象双击图标一闪就退日志里只有一行 Unrecognized VM option现象启动画面出现不到一秒直接消失idea.log里没有业务日志只有 JVM 层的Unrecognized VM option UseConcMarkSweepGC或Error: Could not create the Java Virtual Machine。原因2020.1.4 跑在 JBR 11 上2022.2 跑在 JBR 17 上。JDK 14 移除了 CMS 收集器老 vmoptions 里的-XX:UseConcMarkSweepGC、-XX:CMSClassUnloadingEnabled、-XX:CMSInitiatingOccupancyFractionxx全部变成非法参数JVM 拒绝启动。解决用bin\idea.batmacOS/Linux 用bin/idea.sh从命令行前台启动错误会直接打到终端。删掉所有CMS开头的行和对应的-XX:UseParNewGC用-XX:UseG1GC替代再启动。教训是跨大版本迁移时vmoptions 要当成代码 review 一遍而不是复制粘贴。5.2 现象把整个 plugins 目录拷过去IDE 卡在启动界面不动现象迁完配置后 IDE 停在启动画面进度条卡在Loading plugins几分钟后弹出一个插件异常对话框或者干脆不再响应。原因插件兼容性由插件包内META-INF/plugin.xml的since-build/until-build决定。2020.1.4 对应的 IDE build 号形如201.xxxx2022.2 形如222.xxxx前三位是年份和月份。until-build201.*的插件在新版本上不会被加载但插件之间还有依赖关系——A 插件加载失败会拖死依赖它的 B 插件最终表现就是启动卡死。另外插件目录里还留着plugins/name/lib/*.jar的旧版本版本冲突时异常信息极其含糊。解决不要整包拷。先在旧机器上Settings → Plugins截图或用CtrlAltS搜plugin记录清单到新机器上从插件市场重装。离线环境就把.jar或.zip拷过去用Plugins → 齿轮 → Install Plugin from Disk单个安装装之前解压看META-INF/plugin.xml里的idea-version是否覆盖222.*。已经卡住的兜底方案关掉 IDE把config/plugins整个改名成plugins_bak再启动进去后逐个装回来。5.3 现象文件内容对控制台中文输出全是问号现象代码里的中文注释显示正常但运行程序时System.out.println(中文)输出成一串问号或者日志文件里是乱码。2020.1.4 上一直好的项目换到 2022.2 就出问题。原因2022.2 用的 JBR 17 默认file.encodingUTF-8而 2020.1.4 的 JBR 11 在中文 Windows 上默认是 GBK。如果运行配置的 VM options 里硬写了-Dfile.encodingGBK或者MAVEN_OPTS里带着老参数搬到新版本上就会让标准输出按错误编码解码。另一个来源是 properties 文件的Transparent native-to-ascii conversion开关不一致同一份文件在两个版本上的解析结果不同。解决三步一起做——Settings → Editor → File Encodings三处全设 UTF-8删掉运行配置和MAVEN_OPTS里所有手写的-Dfile.encoding让默认值生效properties 的转码开关全组统一。改完用System.getProperty(file.encoding)打一行确认别靠肉眼看。5.4 现象code style 导入了格式化和同事还是不一致现象.editorconfig提交了.idea/codeStyles/也提交了两个人CtrlAltL出来的结果还是不同尤其是 import 顺序和空行。原因三个来源同时生效且优先级容易搞混——.editorconfig里出现的属性会覆盖 IDE 的 code style 方案方案没显式出现的项则回落到Default此外 Scheme 如果停在Default而不是Project提交上去的Project.xml根本没被读取。还有一种情况是.editorconfig写在子模块目录里但缺少root true向上查找时命中了用户目录下的另一份。解决先确认Settings → Editor → Code Style顶部 Scheme 显示的是Project再确认Settings → Editor → Code Style里Enable EditorConfig support处于勾选状态并清楚它优先。然后做一次对照实验拿同一个文件在两个版本上各格式化一次git diff看差异落在哪一行差异行对应的就是那条没对齐的规则回到.editorconfig补上。别试图靠肉眼比对设置树。5.5 现象Invalidate Caches 之后索引反而更慢第二次打开还是慢现象怀疑索引坏了File → Invalidate Caches / Restart点了好几次每次重建索引十几分钟重建完跳转依然慢Find Usages卡顿。原因Invalidate Caches不是万能药。2022.2 引入了共享索引机制首次打开大项目时会尝试下载预建的 JDK 和库索引内网环境下下载超时会让索引流程反复重试看起来就像「一直在建索引」。另外频繁清缓存会把本地历史和编译缓存一起清掉反而增加后续开销。解决先看Help → Show Log里有没有共享索引相关的超时记录有的话去Settings → Tools → Shared Indexes关掉自动下载改为纯本地索引。确实需要重建时直接关掉 IDE 删掉system目录比点菜单更彻底一次重建后不要反复清。判断索引是否真的坏了的标准是「跳转错位、同名类跳错」而不是「感觉慢」——慢通常是堆太小或idea.max.intellisense.filesize之外的 IO 问题。6.本文还有配套的精品资源点击获取