2025年1月的版本现已推出，关于这个版本我们之前已有讨论；如今，2025.1版本中的K2模式已设定为默认设置。

可以预见，这个版本可能会包含不少大坑，为下个 祈祷。

可以明确的是，尽管K1模式依旧可供选择，K2模式已设定为默认设置，然而K1模式将不再接入新的语言特性以及IDE的优化，因此，在2025.1版本中，你仍旧可以在相应位置将K2模式关闭，但这只能算是权宜之计，暂时的应对之策而已。

"K2" 代表的是集成于插件中的代码分析K2编译器的内部版本，与之相对的是K1模式，该模式采用K1编译器。IDEA内置的编译器版本与项目构建文件中指定的版本完全独立，尽管如此，它仍有可能对项目支持的版本范围产生影响。

我们之前已提及，IDEA的K2模式并不受项目构建配置中指定的编译器版本所限制。K2模式意味着IDE对编辑场景的支持进行了近乎全面的重新编写。采用K2编译器，用户能够享受到：

因此，依托于K2编译器强大功能的K2模式，在代码分析、自动补全以及导航效率上实现了显著提升，这一进步在全新的集成开发环境中具体表现为：

IDE长期严重依赖K1，因此在转向K2的过渡阶段，不得不进行大量的代码重写和功能上的重新构建，这也是K2至今仍在持续优化和完善的关键所在。

在K1至K2的演变过程中，最显著的变化之一是引入了全新的API，这一API提供了一种明确且稳定的途径来获取代码的相关信息，同时无需依赖于编译器的内部构造。

在K2模式下，API采用了模块化的架构设计，并具备IDE的功能支持，例如自动补全和代码检查。此外，它能够独立调用编译器的特定分析阶段，比如进行解析或类型检查，以此避免进行冗余的全量分析，进而有效提升整体性能。

K2 编译器不再使用 K1 版本中隐含的方式，而是改用了显式的分阶段代码分析结构。在 K2 编译器中，代码分析被划分为不同的阶段（例如，对类进行计算，处理 TYPEs 的函数 types），每个阶段都会为抽象语法树（AST）逐步增加语义层面的信息。

此外，在K1模式下，API的分析功能往往受到一个全局解析锁的限制，比如Find这样的操作会锁定该锁，进而使得其他功能，诸如代码高亮和补全等，无法同时进行，从而形成了性能上的瓶颈。

K2 编译器的解析逻辑具有并发容错能力，API 则巧妙地利用了这一特性，成功去除了全局锁的限制。如今，API 能够并行处理多个声明的分析任务，即便是在两个函数相互调用的复杂场景下，也能保持高效运作。

image-

尽管K2编译器现阶段仍采用单一线程进行代码分析（尽管多模块并行编译已实现多核技术的应用），然而，其当前的并发设计为将来实现多线程分析打下了坚实的基础，并且后续的API将能够实现无障碍的兼容。

在插件迁移适配过程中，API 发挥了至关重要的作用，它将所有繁杂的解析逻辑进行了封装，同时提供了行为明确且易于预测的记录抽象。开发者仅需调用所需语义代码信息片段，API 即将负责处理所有延迟与并行分析，并缓存分析结果。

若需确定表达式的种类，开发者仅需调用该库所提供的特定属性，若对类型尚不明确，系统将自动进行声明体内的内容分析。

实际上intellij idea 2025，不论您的项目是否为K2，都能在新IDE的K2模式下体验到性能的显著增强；此外，若您正在开发或使用插件，可能还需对某些依赖旧插件的依赖项进行迁移，比如：

此外，正如先前所述，对于某些新增功能，例如2.1版本新增的支持，其应用范围将仅限于K2模式的集成开发环境，具体而言：

最终，即将到来的更新同样会默认启动K2模式，因此在进行下一个版本AS的开发时，我们必须谨慎行事，因为很难预料到其中可能存在的各种问题。

当然，最后还是要强调：

K2 Mode通过运用K2编译器的前端部分，即解析与语义分析环节，提升了IDE的代码理解功能。然而，它并不直接介入项目的编译过程。此功能主要针对的是IDE的交互体验，其作用范围被限定在这一领域。

因此，从理论上讲，即便你的项目选择了K1，这并不会对你体验K2模式造成任何影响；然而，若你的项目采用了K2，我们强烈建议你启动K2模式，以便能够体验其带来的全新功能。

那么intellij idea 2025，你已经体验过 K2 模式了么？

参考资料

如有侵权请联系删除！