企业官网建设流程全解析

1. 为什么“全局配置”值得单独拎出来讲

很多人用 IDEA 的习惯是：装完就用，遇到问题再改。项目换一个，配置重来一遍，编码格式不对了改一下，Maven 路径不对了再改一下，JDK 版本冲突了又改一下。这种“打补丁式”的配置方式，在只维护一两个项目的时候还能凑合，一旦同时涉及多个项目、多套技术栈、多个 JDK 版本，问题就会集中爆发。

我见过太多这样的情况：同一个团队里，A 同学提交的代码用的是 UTF-8，B 同学本地默认是 GBK，结果中文注释在别人机器上全是乱码；C 同学把 Maven 配到了项目级别，换了个项目又得重新配一遍；D 同学每次新建项目都要手动调一遍字体、快捷键、代码模板，一天下来光配置就耗掉半小时。这些问题的根源只有一个：没有把 IDEA 的全局配置当回事。

所谓全局配置，就是那些对所有项目生效、只需要设置一次、之后新建项目自动继承的设置项。它和项目级配置最大的区别在于作用域：项目级配置跟着项目走，换项目就失效；全局配置跟着 IDE 走，一次配好，处处生效。把该放全局的东西放到全局，把该放项目的东西留在项目，这个边界划清楚了，你的开发效率会有肉眼可见的提升。

这篇内容适合所有正在用或准备用 IDEA 的开发者，不管你是刚接触的新手，还是用了几年但一直没系统整理过配置的老手。我会从配置的存储机制讲起，把编码、JDK、Maven、快捷键、代码模板、插件、内存调优这些核心模块逐个拆开，告诉你每一项为什么要这么配、配在哪里、配完怎么验证。中间会穿插我自己踩过的坑和团队里反复出现的典型问题，尽量让你看完就能直接抄作业。

2. 全局配置的存储机制与备份逻辑

2.1 配置到底存在哪里

IDEA 的配置分两个大类存放，理解这个分类是做好全局配置的前提。

第一类是全局配置目录，也叫配置根目录。这个目录存放的是 IDE 级别的设置，包括快捷键映射、代码风格、文件模板、插件列表、工具窗口布局等。它不随项目变化，所有项目共享同一份。在 Windows 上通常位于用户目录下的应用数据文件夹里，在 macOS 上位于用户资源库的应用支持目录下，在 Linux 上位于用户主目录的隐藏配置文件夹中。具体路径会随 IDEA 版本变化，最稳妥的方式是通过 IDE 内部的“帮助”菜单找到“编辑自定义 VM 选项”或“属性”入口，里面会直接显示当前配置目录和系统目录的真实路径。

第二类是系统目录，存放的是缓存、索引、日志、本地历史等运行时数据。这个目录可以删，删了之后 IDEA 会重新建立索引，不会丢失你的配置。但配置目录不能随便删，删了你的快捷键、模板、插件全没了。

还有一类容易被忽略的是项目级配置，存放在项目根目录下的.idea文件夹里。这个文件夹里的东西是跟着项目走的，比如项目的 JDK 设置、模块依赖、运行配置等。团队协作时，.idea里的一部分文件应该纳入版本控制（比如代码风格、检查规则），另一部分应该忽略（比如本地路径、工作区文件）。

2.2 为什么要做配置备份

我吃过一次亏：升级 IDEA 大版本的时候，安装程序问我要不要导入旧配置，我手快点了“不导入”，结果几年的快捷键习惯、自定义模板、插件配置全部归零。从那以后，我养成了一个习惯——每次大版本升级前，先手动导出配置。

IDEA 提供了官方的导出功能，可以把全局配置打包成一个压缩文件。操作路径是“文件”菜单里的“管理 IDE 设置”，然后选择“导出设置”。导出的内容包括快捷键、代码风格、插件列表、工具窗口布局等。导入的时候走同样的入口选“导入设置”即可。

但官方导出有个局限：它不包含插件本身的二进制文件，只记录插件列表。也就是说，导入到一台新机器后，IDEA 会根据列表去重新下载插件，如果网络不通或者插件下架了，就装不回来。所以更彻底的备份方式是直接复制整个配置目录，把配置目录和系统目录一起打包。系统目录虽然可以重建，但带着它迁移能省去重新索引的时间，对于大型项目来说，重新索引可能要十几分钟甚至更久。

提示：配置目录里有一个关键文件记录了你的插件启用状态和顺序，直接复制配置目录时，建议先关闭 IDEA，避免文件被占用导致复制不完整。

2.3 配置同步的取舍

IDEA 内置了设置同步功能，可以把你的一部分配置上传到账号里，换机器登录后自动拉取。这个功能适合个人开发者，但有几个点要注意。

首先，同步的内容是有限制的，不是所有配置都能同步。快捷键、代码风格、插件列表这些核心项支持同步，但一些涉及本地路径的配置（比如 Maven 本地仓库路径、JDK 路径）不会同步，因为不同机器的路径可能不一样。其次，如果你在多台机器上同时改配置，同步可能产生冲突，IDEA 会提示你选择保留哪一份。我的建议是：主力机器上精心配好，然后开启同步，其他机器登录后拉取即可，不要在副机上做大改。

对于团队场景，更推荐的做法是把代码风格、检查规则这类需要统一的配置导出成文件，放进项目的版本控制里，让每个成员导入。这样既保证了团队一致性，又不依赖个人的同步账号。

3. 编码与文件格式的全局统一

3.1 编码问题的根源

乱码是中文开发者最常遇到的问题，没有之一。它的本质是：文件写入时用的编码和读取时用的编码不一致。比如文件本身是 UTF-8 编码，但 IDEA 用 GBK 去读，中文就变成了问号或方块。

IDEA 的编码设置分三个层级：全局编码、项目编码、文件编码。全局编码在设置里的“编辑器 - 文件编码”页面配置，它决定了新建文件的默认编码。项目编码在项目设置里配置，会覆盖全局设置。单个文件也可以单独指定编码，在编辑器右下角的状态栏可以切换。

我的建议很明确：全局统一设为 UTF-8，项目级也设为 UTF-8，不要用 GBK。原因有三：第一，UTF-8 是跨平台、跨语言的通用编码，兼容性最好；第二，主流开源项目、主流框架的源码基本都是 UTF-8；第三，GBK 只覆盖中文字符，遇到日文、韩文、特殊符号就会出问题。

3.2 需要同步调整的几个关联项

光改文件编码还不够，有几个关联设置必须一起改，否则还是会出乱码。

属性文件的编码。Java 项目里的.properties文件在历史上默认使用 ISO-8859-1 编码，这是 Java 规范遗留的问题。IDEA 提供了一个选项，可以勾选“以 UTF-8 读取属性文件”，勾上之后，properties 文件里的中文就能正常显示。但要注意，这个选项只影响 IDEA 的读取和显示，如果代码里用Properties.load()加载，仍然需要按 UTF-8 处理，否则运行时还是乱码。

控制台输出编码。有时候文件编码没问题，但控制台打印中文是乱码。这通常是 JVM 的默认字符集和终端编码不匹配导致的。解决办法是在运行配置的 VM 参数里加上-Dfile.encoding=UTF-8，强制 JVM 用 UTF-8 输出。如果是 Maven 项目，还可以在 Maven 的编译插件里配置编码参数，确保编译阶段也用 UTF-8。

换行符的统一。Windows 用 CRLF，Linux 和 macOS 用 LF。团队协作时如果不统一，Git 会提示大量文件被修改，实际上只是换行符变了。IDEA 在“文件编码”页面下方有换行符设置，建议全局设为 LF，或者在项目里配置.gitattributes文件来强制统一。

3.3 编码配置的验证方法

配完之后怎么确认生效了？我通常用三个步骤验证。

第一步，新建一个文件，随便输入几个中文，保存后看右下角状态栏显示的编码是不是 UTF-8。第二步，找一个已有的、确定是 UTF-8 的中文文件，用 IDEA 打开，看中文是否正常显示。第三步，运行一个会输出中文的程序，看控制台是否正常。

如果三步都通过，说明编码配置没问题。如果某一步出问题，就回到对应的设置项检查。这里有个经验：改完编码设置后，最好重启一次 IDEA，因为有些编码相关的缓存需要重启才会刷新。

4. JDK 与编译环境的全局规划

4.1 多版本 JDK 的管理思路

现在的 Java 项目，JDK 版本跨度很大。老项目可能还在用 JDK 8，新项目可能已经上了 JDK 17 甚至 JDK 21。如果每次打开项目都手动切换 JDK，效率太低。正确的做法是在全局配置里注册所有常用的 JDK 路径，然后在项目级别选择用哪个。

在设置里的“构建、执行、部署 - 构建工具 - 编译器 - Java 编译器”页面，或者在“项目结构”的 SDK 管理页面，可以添加多个 JDK。添加时给每个 JDK 起一个清晰的名字，比如“JDK 8 - 公司老项目”“JDK 17 - 新项目默认”“JDK 21 - 尝鲜用”。名字起得好，切换的时候一眼就能认出来。

添加完 JDK 后，还要设置一个默认 SDK。这个默认 SDK 会在新建项目时自动使用。我一般把最常用的那个版本设为默认，比如 JDK 17。这样新建项目不用改，老项目打开时如果检测到 JDK 不匹配，IDEA 会提示你切换，点一下就行。

4.2 编译级别与语言级别的区别

这里有个概念容易混淆：编译级别和语言级别不是一回事。

编译级别（target bytecode version）决定生成的.class文件能在哪个版本的 JVM 上运行。比如编译级别设为 8，生成的 class 文件就能在 JDK 8 及以上的 JVM 上运行。语言级别（language level）决定 IDEA 允许你使用哪个版本的 Java 语法特性。比如语言级别设为 8，你就不能用var关键字（JDK 10 引入）和record（JDK 16 引入）。

理想情况下，这两个级别应该和项目实际使用的 JDK 版本一致。但有时候为了兼容性，会故意把编译级别调低。比如用 JDK 17 开发，但编译级别设为 8，这样打出来的包能在老环境的 JDK 8 上跑。这种场景下，语言级别可以保持 17，让你用新语法，但编译产物兼容老版本。

在全局配置里，我建议把默认的编译级别和语言级别都设为你最常用的 JDK 版本。项目打开后如果发现不匹配，再单独调整。IDEA 在打开项目时会读取 Maven 或 Gradle 的配置，自动设置对应的级别，所以大多数时候不用手动改。

4.3 编译器参数的全局预设

有些编译参数是通用的，适合放在全局配置里。比如-parameters参数，它会让编译器保留方法参数名，很多框架（比如 MyBatis、Spring）依赖这个来减少配置。还有-Xlint:all可以开启所有编译警告，帮你提前发现潜在问题。

在“Java 编译器”页面的“附加命令行参数”里可以填这些。但要注意，全局参数会应用到所有项目，如果某个项目有特殊需求，可能会冲突。所以我的做法是：全局只放最通用、最无害的参数，比如-parameters。其他有争议的参数放到项目级配置里。

另外，编码参数-encoding UTF-8也建议放在全局，确保所有项目的编译阶段都用 UTF-8，避免因平台默认编码不同导致的编译乱码。

5. Maven 与构建工具的全局调优

5.1 Maven 全局配置的三个关键点

Maven 是 Java 项目最常用的构建工具，它的全局配置主要涉及三个地方。

Maven 主路径。IDEA 自带了 Maven，但自带的版本通常比较旧，而且和命令行用的 Maven 可能不一致。我建议在全局配置里指定自己安装的 Maven，保持 IDE 和命令行行为一致。路径在“构建工具 - Maven”页面的“Maven 主路径”里设置。

用户设置文件。这个文件（通常叫settings.xml）里配置了本地仓库路径、镜像源、认证信息等。IDEA 默认会读取用户目录下的.m2/settings.xml，但有时候我们会用自定义路径。在全局配置里明确指定这个文件的位置，可以避免每次新建项目都要重新配。

本地仓库路径。默认在用户目录的.m2/repository下。如果 C 盘空间紧张，或者想把仓库放到更快的磁盘上，可以在这里改。改完之后，所有项目都会用新的仓库路径，不用每个项目单独配。

5.2 镜像源与依赖下载优化

依赖下载慢是很多人的痛点。解决办法是配置镜像源，把默认的中央仓库替换成更快的镜像。在settings.xml的<mirrors>节点里配置即可。

配置镜像时有个细节：镜像的mirrorOf要写对。如果写*，表示所有仓库都走这个镜像，包括一些第三方仓库。如果只想替换中央仓库，写central即可。我一般写*，因为大多数第三方仓库在国内访问也不稳定，统一走镜像更省心。

除了镜像，还可以调整 Maven 的下载策略。在“Maven - 导入”页面，有一个“自动下载”相关的选项，可以设置是否自动下载源码和文档。源码和文档能帮你在调试时看到库的内部实现，但下载它们会拖慢首次导入的速度。我的建议是：首次导入时关闭源码和文档下载，等项目跑起来后再按需下载。

5.3 Gradle 用户的对应配置

如果你的项目用 Gradle，思路类似。全局配置里可以指定 Gradle 的安装路径、JVM 参数、离线模式等。Gradle 的依赖缓存路径也可以通过环境变量或配置文件调整。

Gradle 有一个和 Maven 不同的地方：它支持“守护进程”（daemon），守护进程会常驻内存，加速后续构建。在全局配置里可以调整守护进程的 JVM 参数，比如堆内存大小。对于大型项目，适当调大堆内存能明显减少构建卡顿。

注意：Maven 和 Gradle 的全局配置改动后，建议执行一次“重新导入”或“刷新”，让 IDEA 重新读取配置。有时候配置改了但没生效，就是因为没有触发重新加载。

6. 快捷键与编辑器行为的个性化

6.1 快捷键方案的选择

IDEA 提供了几套预设的快捷键方案，比如默认方案、Eclipse 方案、VS 方案等。如果你是从其他 IDE 转过来的，可以先用对应的方案过渡，减少学习成本。但长期来看，我建议逐步迁移到 IDEA 默认方案，因为默认方案的快捷键覆盖最全，插件和文档也大多以默认方案为准。

切换方案在“快捷键”页面顶部选择。切换后，你可以看到所有快捷键的映射关系。如果某个快捷键和系统或其他软件冲突，IDEA 会标红提示，你可以右键选择移除或重新分配。

我个人的习惯是：保留默认方案，只改少数几个高频操作的快捷键。比如我把“最近打开的文件”改成了更顺手的组合，把“全局搜索”也调整了一下。改的时候要注意，不要和已有快捷键冲突，改完最好用几天，形成肌肉记忆。

6.2 编辑器行为的细节调整

编辑器行为里有很多小设置，调好了能显著提升手感。

自动导入。在“编辑器 - 常规 - 自动导入”页面，可以设置自动导入包和自动删除无用导入。我一般把“自动导入”设为“始终”，把“自动删除无用导入”也打开。这样写代码时不用手动按快捷键导包，删掉代码后无用的 import 也会自动清理。

代码补全。IDEA 的补全默认是区分大小写的，这有时候很烦。在“编辑器 - 常规 - 代码补全”里，可以把“区分大小写”改为“无”，这样输入小写也能匹配到大写的类名。另外，可以调整补全的排序规则，把常用的补全项排前面。

显示设置。行号、方法分隔线、空白字符这些显示项，在“编辑器 - 常规 - 外观”里配置。我建议打开行号和方法分隔线，空白字符可以设为“仅前导和尾随”，这样能看出缩进问题，又不会满屏都是小点。

6.3 代码模板的全局定义

代码模板（Live Templates）是提升编码速度的利器。比如输入sout自动展开为System.out.println()，输入fori自动生成 for 循环。IDEA 内置了大量模板，你也可以自定义。

自定义模板在“编辑器 - 实时模板”页面。新建模板时，要指定一个缩写（触发词）、一段模板文本、以及适用的上下文（比如 Java 代码、注释、HTML 等）。模板文本里可以用$变量$定义占位符，用$END$定义光标最终位置。

我常用的几个自定义模板：一个是日志输出，缩写logd，展开为带类名的日志语句；一个是单元测试方法，缩写testm，展开为带@Test注解的方法框架；还有一个是 try-catch 块，缩写tryc，展开为带日志的异常捕获。这些模板一次定义，全局可用，日积月累能省下大量敲键盘的时间。

7. 插件管理与性能平衡

7.1 必装插件与选装插件

插件是 IDEA 的灵魂，但装多了会拖慢启动和运行速度。我的原则是：只装真正高频使用的，低频的用的时候再装。

必装类插件通常包括：代码规范检查工具、Git 增强工具、数据库连接工具、REST 接口测试工具。这些几乎每天都会用到，装了能明显提升效率。

选装类插件包括：主题美化、翻译工具、JSON 格式化、正则测试等。这些看个人习惯，用得上就装，用不上就不装。

有一个坑要注意：插件之间可能冲突。比如两个插件都修改了同一个菜单项，或者都监听了同一个事件，可能导致 IDEA 卡顿甚至崩溃。如果装完插件后 IDEA 变得不稳定，可以尝试禁用最近装的插件，逐个排查。

7.2 插件对启动速度的影响

插件越多，IDEA 启动越慢。这是因为每个插件在启动时都要加载自己的类和资源。我做过一个粗略的测试：在一台普通配置的机器上，不装任何第三方插件时，IDEA 启动大约 5 秒；装了 10 个常用插件后，启动时间增加到 8 到 10 秒；装了 20 个以上插件后，启动时间可能超过 15 秒。

所以，定期清理不用的插件很有必要。在“插件”页面，可以按“已安装”筛选，把最近几个月没用过的插件禁用或卸载。禁用比卸载更温和，如果以后又需要，直接启用即可，不用重新下载。

7.3 插件配置的备份

插件的配置（比如某个插件的自定义规则、快捷键）通常存在配置目录里。做配置备份时，插件配置会一起被备份。但插件的二进制文件不在配置目录里，而是在系统目录或单独的插件目录里。如果直接复制配置目录到新机器，插件需要重新下载。

为了减少重新下载的麻烦，可以在导出设置时勾选“包含插件”，这样导出的压缩包里会带上插件的安装文件。不过这样导出的包会比较大，传输起来慢一些。取舍看你的网络情况。

8. 内存与性能的全局调优

8.1 堆内存的合理设置

IDEA 是基于 Java 的，它的性能很大程度上取决于 JVM 的堆内存设置。默认的堆内存可能偏小，打开大项目时会卡顿甚至卡死。

堆内存的设置文件是配置目录下的 VM 选项文件。在这个文件里，可以调整-Xmx（最大堆内存）和-Xms（初始堆内存）。我的经验值是：8GB 内存的机器，给 IDEA 分配 2GB 到 3GB；16GB 内存的机器，分配 4GB 到 6GB；32GB 以上的机器，可以给到 8GB。不要把所有内存都给 IDEA，因为操作系统、其他软件、以及你运行的程序也需要内存。

-Xms和-Xmx建议设成一样的值，这样可以避免堆内存动态扩展带来的性能波动。比如都设为 4GB。

8.2 垃圾回收器的选择

JVM 的垃圾回收器对 IDEA 的流畅度有影响。默认的回收器在大多数场景下够用，但如果你的项目特别大，或者经常遇到卡顿，可以尝试更换回收器。

在 VM 选项文件里，可以通过-XX:+UseG1GC启用 G1 回收器，它在处理大堆内存时表现更好，停顿时间更短。对于 IDEA 这种交互式应用，低停顿比高吞吐更重要，所以 G1 通常是不错的选择。

还有一个参数-XX:ReservedCodeCacheSize，它控制 JIT 编译代码的缓存大小。IDEA 加载大量类时，这个缓存可能不够用，导致编译变慢。可以适当调大，比如设为 512MB 或 1GB。

8.3 索引与缓存的维护

IDEA 会为项目建立索引，索引让搜索、跳转、补全变得飞快，但索引本身也占资源。如果索引损坏，会出现搜索不到类、跳转错误等问题。解决办法是“文件”菜单里的“清除缓存并重启”，IDEA 会删除旧索引并重新建立。

清除缓存是个耗时操作，大项目可能要几分钟到十几分钟。所以不要频繁做，只在确实出现索引相关问题时才做。平时可以通过“文件 - 省电模式”来临时关闭索引和检查，省电模式下 IDEA 几乎不占 CPU，但补全和跳转也会失效，适合在只读代码或演示时使用。

9. 常见问题与排查技巧实录

9.1 配置不生效的排查思路

配置改了但没生效，是最让人头疼的问题。我总结了一个排查顺序。

先确认改的是全局配置还是项目配置。如果项目里有覆盖全局的设置，全局改了也不会生效。在设置页面，如果某个项旁边有“项目”或“默认”的标记，说明它分两级，要确认改的是哪一级。

再确认是否需要重启。有些配置（比如 VM 选项、插件）需要重启 IDEA 才生效。改完这些配置后，IDEA 通常会提示重启，点一下就行。

最后确认是否有缓存干扰。如果配置确实改了、也重启了，但还是不生效，可以尝试清除缓存。清除缓存会重建索引，能解决大部分“玄学”问题。

9.2 典型问题速查表

9.3 几个容易忽略的细节

文件编码的 BOM 问题。UTF-8 有一种带 BOM 的变体，会在文件开头插入几个不可见字符。有些工具能识别，有些不能，可能导致编译错误。IDEA 在保存 UTF-8 文件时默认不带 BOM，这个设置不要改。

换行符的自动检测。IDEA 打开文件时会自动检测换行符类型，如果检测错了，可以手动在状态栏切换。团队协作时，建议在项目里统一换行符，避免 Git 产生无意义的 diff。

配置目录的权限。如果配置目录没有写权限，IDEA 可能无法保存配置，表现为改了设置重启后又变回去了。检查配置目录的权限，确保当前用户有读写权限。

多版本 IDEA 共存。如果你同时装了多个版本的 IDEA，它们的配置目录是分开的。升级版本时，可以选择导入旧版本的配置，也可以选择不导入。导入能保留习惯，不导入则从零开始。根据实际情况选择。

10. 团队协作中的配置统一实践

10.1 哪些配置应该纳入版本控制

团队协作时，有些配置需要统一，有些则应该保留个人习惯。我的划分标准是：影响代码产物的配置统一，影响个人效率的配置自由。

应该纳入版本控制的：代码风格（缩进、空格、换行）、代码检查规则、文件模板（比如新建类时的默认注释）、Maven 或 Gradle 的构建配置。这些配置直接影响提交的代码，必须统一。

不应该纳入版本控制的：快捷键、主题、字体大小、工具窗口布局、本地路径相关的配置。这些是个人偏好，不影响代码，强行统一反而降低效率。

10.2 配置文件的导入与同步

IDEA 支持把代码风格和检查规则导出成 XML 文件。团队可以约定一个共享目录，把这些 XML 放进去，每个成员导入一次。导入后在项目级生效，不会覆盖个人的全局设置。

对于 Maven 项目，pom.xml本身就是团队共享的，里面的插件配置、编码配置、编译级别配置会自动应用到所有成员。所以 Maven 项目的构建配置天然就是统一的，不需要额外操作。

对于 Gradle 项目，build.gradle也是共享的。但 Gradle 的全局配置（比如 Gradle 安装路径、JVM 参数）是个人级的，需要每个成员自己配。

10.3 新人入职的配置清单

团队里来新人时，如果让他自己摸索配置，可能要折腾好几天。我通常会准备一份配置清单，让新人照着做。

清单内容包括：安装指定版本的 JDK 并配置环境变量；安装 IDEA 并导入团队共享的代码风格文件；配置 Maven 的 settings.xml，指向团队统一的镜像和仓库；安装团队约定的必装插件；调整内存参数到推荐值；导入快捷键方案（如果团队有统一方案）。

这份清单能让新人在半天内把环境配好，直接进入开发状态。清单本身也可以放进团队文档里，随时更新。

11. 我个人的配置习惯与踩坑记录

11.1 我的全局配置清单

说说我自己的配置习惯，供你参考。

编码方面，全局 UTF-8，属性文件勾选 UTF-8 读取，换行符统一 LF。JDK 方面，注册了 JDK 8、11、17、21 四个版本，默认用 17。Maven 方面，指定了自己安装的 Maven，settings.xml 指向公司镜像，本地仓库放在 D 盘。快捷键方面，保留默认方案，只改了“最近文件”和“全局搜索”两个。插件方面，只装了 Git 增强、数据库工具、REST 测试、代码规范检查这四个。内存方面，-Xmx设为 4GB，-Xms也是 4GB，启用了 G1 回收器。

这套配置我用了两年多，换过三台机器，每次都是复制配置目录加导入设置，十分钟就能恢复工作环境。

11.2 踩过的坑

第一个坑是升级 IDEA 时没备份配置。那次升级后，我的自定义模板全没了，花了一个多小时重新配。从那以后，我每次升级前必导出配置。

第二个坑是Maven 镜像配错了mirrorOf。我一开始写的是*，结果公司内部仓库的依赖也走了外部镜像，导致内部包下载失败。后来改成只替换central，问题解决。

第三个坑是堆内存设得太大。我有一次把-Xmx设成了 8GB，结果机器本身只有 16GB 内存，IDEA 占了一半，其他软件卡得不行。后来降到 4GB，整体反而更流畅。

第四个坑是插件装太多。有段时间我装了二十多个插件，IDEA 启动要二十多秒，而且经常卡顿。后来清理到只剩四个，启动恢复到八秒左右。

11.3 给不同阶段开发者的建议

如果你是刚接触 IDEA 的新手，我的建议是：先用默认配置，遇到问题再改。不要一上来就照着网上的“最佳配置”大改，因为你还不清楚每个配置项的作用，改错了反而添乱。等用了一段时间，对 IDEA 有感觉了，再逐步调整。

如果你是有一定经验的开发者，建议你系统整理一次全局配置。把编码、JDK、Maven、快捷键、模板、插件、内存这几块过一遍，该统一的统一，该备份的备份。这一次整理可能花你一两个小时，但之后能省下无数个一小时。

如果你是团队的技术负责人，建议你制定一份团队配置规范，把需要统一的配置固化下来，让每个成员导入。同时准备一份新人配置清单，降低入职门槛。团队配置统一了，代码风格、构建行为、依赖版本这些容易出问题的地方就都有了保障。

配置这件事，说到底是为了让工具适应人，而不是让人适应工具。花点时间把全局配置理顺，让 IDEA 真正成为你顺手的那把刀，而不是每天都要磨的钝器。