IDEA 2026.2 EAP 4 更新清单：从 Java 25 到 Kotlin K2，哪些值得升级？

你有没有这种感觉：

IDE 每次发 EAP，Release Notes 密密麻麻一大页，看起来全是 issue 编号、Subsystem、Bug、Task、Feature。

你知道它肯定有用。

但你真正关心的是：

• • 我现在要不要升级？
• • 对 Java / Kotlin / Spring / Gradle 项目有没有影响？
• • 哪些是新能力，哪些只是修 bug？
• • 有没有可能踩坑？

如果你只是把 Release Notes 从头扫到尾，大概率会被 100 多条记录淹没。

所以这篇不逐条翻译。

我会把 IntelliJ IDEA 2026.2 EAP 4（262.6653.22 build）的更新，整理成一份更适合开发者快速判断的清单：8 个重点方向 + 具体影响 + 建议动作。

看完你基本就能判断：这版 EAP 是“可以尝鲜”，还是“先观望”。

先说结论：这版不是大功能爆发，而是“体验修补 + 平台打底”

从这份 Release Notes 看，IDEA 2026.2 EAP 4 的主旋律不是某个炫酷大功能，而是三类变化：

1. 1. Java / Kotlin 日常编码体验继续打磨
2. 2. Persistence、Spring、Web 等框架支持修复误报和解析问题
3. 3. IDE 平台底层继续处理性能、插件、远程开发、UI 稳定性问题

这类版本最适合两类人关注：

• • 一类是插件开发者、框架重度用户、团队工具链负责人；
• • 另一类是正在被某个 IDE bug 卡住的开发者。

如果你只是稳定写业务代码，这版不一定要立刻升级主力环境。

但如果你关注 Java 25、Kotlin K2、Gradle 9、HQL/JPQL 解析、Remote Development、IDE 平台插件模型，这版值得认真看。

图 1：IDEA 2026.2 EAP 4 的 8 个关注点

1. Java：Java 25 的细节支持开始补齐

这次 Java 相关更新里，最值得注意的是一个 Feature：

Support .iop postfix completion for Java 25 IO.println()

这看起来是个很小的功能。

但它释放的信号很明确：IDEA 正在继续跟进新版本 Java 的语法、API 和编码体验。

如果你已经在关注 Java 25，那么这种 postfix completion 的小补丁，实际体验会很明显。

因为它不是“能不能写”的问题，而是“写起来顺不顺”的问题。

比如以前你可能需要手动敲 IO.println(...)，现在可以通过 postfix completion 更快完成输出表达式。

对普通业务开发来说，这不是升级理由。

但对尝鲜新 JDK、写教学示例、做语言特性演示的人来说，这类支持会让 IDE 更像“跟上语言节奏”的工具。

建议动作：

如果你的团队还在 Java 17 / 21 LTS，不需要因为这个点升级。

但如果你负责 Java 新版本预研，可以把这版 EAP 放进测试环境，顺手验证 Java 25 相关补全、语法高亮和运行配置是否稳定。

一句话总结：Java 新版本支持，往往先从这些小体验开始。

2. Java Code Completion：补全系统继续迁移到 ModCommand API

Release Notes 里还有一条任务：

Convert reflection completion to ModCommand API

普通用户看到这句可能会跳过。

但如果你是 IntelliJ 平台插件开发者，或者你经常关注 IDE 内部架构，这条值得留意。

ModCommand API 是 JetBrains 近年来在意图动作、快速修复、代码修改命令等能力上的重要方向。把 reflection completion 迁移过去，意味着补全相关动作会逐步纳入更统一的命令模型。

它可能不会立刻改变你的 UI。

但长期看，它会影响：

• • 快速修复的稳定性；
• • 代码修改动作的可组合性；
• • 插件 API 的迁移方向；
• • AI / intention / completion 之间的协作方式。

同时，这次还修了一个补全相关 bug：

Command Completion: Typo: Rename to action does nothing

这类问题看似小，但它影响的是你每天频繁使用的“边写边修”体验。

建议动作：

插件开发者可以开始关注 ModCommand API 的迁移节奏。

普通开发者只需要知道：如果你之前遇到补全后快速修复不生效、rename action 无响应，这版可能有所改善。

一句话总结：补全不是单点功能，它正在变成 IDE 自动化修改能力的一部分。

3. Gradle / Maven：构建工具矩阵继续前移

构建系统方面，这版主要有三条：

• • Add Gradle 8.14.5 to the compatibility matrix
• • Add Gradle 9.5.1 to the compatibility matrix
• • Migrate MavenPomPathModuleService

最直观的是 Gradle 兼容矩阵更新。

这意味着 IDEA 对较新 Gradle 版本的兼容测试、识别和集成会继续前移。

对团队来说，这件事很现实：

你升级 Gradle，不只是改 gradle-wrapper.properties。

你还要考虑 IDE 能不能正确导入项目、识别 source set、运行 test task、处理 Kotlin DSL、同步依赖、展示构建错误。

很多团队升级 Gradle 卡住，不是命令行不能跑，而是 IDE 体验变差。

所以这类兼容矩阵更新，虽然不性感，但很重要。

建议动作：

如果你正在从 Gradle 8.x 往 9.x 做预研，可以用 EAP 环境单独导入项目测试：

1. 1. 项目同步是否稳定；
2. 2. 多模块依赖是否识别正确；
3. 3. 测试任务是否能从 IDE 正常运行；
4. 4. Kotlin DSL 是否有明显红线误报；
5. 5. CI 与本地 IDE 的 Gradle 行为是否一致。

一句话总结：构建工具升级，命令行能跑只是第一关，IDE 能舒服用才算完成。

4. Java Debugger / Tests：重点修的是“运行时体验”

这次 Java Debugger 和 Tests 也有不少值得看的点。

Debugger 里有一条 Performance：

Unresponsive IDEA on heavy printing to console

如果你调试过疯狂打印日志的程序，应该知道这种问题有多烦。

程序还没崩，IDE 先卡住了。

日志越多，控制台越沉重，导航、滚动、停止进程都可能变慢。

这版针对 heavy printing to console 的无响应问题做了处理，对测试输出很大、调试日志很多的场景会有帮助。

Java Tests 里还有一个 Feature：

testFramework: support for printing raw service messages

这更偏测试框架和工具集成。

它说明 IDEA 在测试输出协议、服务消息展示方面继续增强，对复杂测试平台、CI 集成、内部测试框架会更有价值。

建议动作：

如果你的项目有这些特征，可以重点验证：

• • 单测输出极多；
• • 控制台打印大对象或大量日志；
• • 测试框架依赖自定义 service messages；
• • 经常从 test console 跳转源码。

一句话总结：调试器和测试窗口的稳定性，往往决定你一天心情好不好。

5. Persistence：Hibernate HQL / JPAQL 误报继续修

这一版 Persistence 相关内容非常集中。

尤其是 Hibernate HQL，出现了一组解析和误报修复：

• • CTEs 下 false-positive duplicate identifier warning；
• • join subquery 的 select 在末尾时报错；
• • ORDER BY / LIMIT 解析问题；
• • FILTER 和 WITHIN GROUP 解析问题；
• • TREAT(... AS ...) 类型处理不准确；
• • COLUMN(...) 参数应被视为 column name；
• • 多个 valid HQL 被标红的问题。

JPAQL 也有类似修复：

• • SELECT SUM() 构造器误报；
• • joined aliases 的 attributes 无法解析。

这类问题对后端开发者影响很直接。

因为它不是运行时报错，而是 IDE 把正确代码标红。

一旦误报多了，你会慢慢不信 IDE。

更麻烦的是，新同事看到红线时，不知道是代码错了，还是 IDE 错了。

所以 Persistence 解析修复的价值，不只是少几条 warning，而是恢复你对代码洞察的信任。

建议动作：

如果你的项目大量使用 Hibernate 6、复杂 HQL、CTE、窗口函数、FILTER、WITHIN GROUP、动态查询，可以把这版 EAP 作为误报验证版本。

重点看两件事：

1. 1. 老版本里被标红但运行正常的查询是否恢复；
2. 2. 新版本有没有引入新的 false positive 或 false negative。

一句话总结：ORM 查询越复杂，IDE 的“别乱报错”越重要。

6. Spring Boot：配置属性和 Bean 导航继续修体验

Spring Boot 这次主要修了配置属性相关问题：

• • List / Map POJO 类型的 configuration properties 默认值不显示；
• • @ConfigurationProperties record 的非 public 属性缺少 gutter icon；
• • 通过 @EnableConfigurationProperties 注册的 bean 无法导航到声明位置；
• • Spring metadata 收集导致高内存使用。

这些问题都很“日常”。

你可能不会因为它们停工。

但它们会持续消耗你的注意力。

比如你点不进配置类声明，就要手动搜索。

默认值不显示，就要来回翻配置文件和代码。

metadata 收集有内存问题，就可能让大型 Spring 项目越来越卡。

建议动作：

Spring Boot 项目可以重点验证三类体验：

1. 1. application.yml 到配置类的跳转；
2. 2. @ConfigurationProperties record 的 gutter icon；
3. 3. 大型项目打开后的内存曲线和索引行为。

一句话总结：Spring 项目越大，配置导航和元数据性能越不是小事。

7. Kotlin：K2 迁移进入“边角料深水区”

Kotlin 相关条目很多，但整体可以归纳成一句话：

K2 IDE 支持继续补齐细节。

这次包括：

• • Port KotlinCleanupInspection to K2；
• • Port AddSpreadOperatorForArrayAsVarargAfterSamFix；
• • Quick-fix to convert implicit context to explicit context argument；
• • K2 下 unused import 的 false positive；
• • Java completion 中降低 suspend functions with Continuation parameter 的优先级；
• • Java 2 Kotlin 转换四斜杠注释失败；
• • Kotlin custom scripting definitions discovery and loading 重做。

这里最值得关注的是：K2 迁移已经不只是“能不能解析 Kotlin 文件”。

它开始进入大量日常边角场景：

• • inspection 是否准确；
• • quick fix 是否合理；
• • Java/Kotlin 混编补全是否聪明；
• • scripting definition 是否加载稳定；
• • Java to Kotlin 转换是否可靠。

这说明 K2 IDE 体验正在从“主路径可用”往“复杂项目可用”推进。

建议动作：

如果你维护 Kotlin 项目，尤其是多模块、混编、自定义脚本、Kotlin DSL 较多的项目，可以用这版观察：

1. 1. false positive 是否减少；
2. 2. quick fix 是否更符合预期；
3. 3. Java 调 Kotlin 时补全排序是否更干净；
4. 4. Kotlin scripting 是否仍有加载问题。

一句话总结：K2 的真正考验，不在 demo，而在你项目里那些奇怪但真实的代码。

8. IDE 平台与 UI：大量修复都在处理“别卡、别乱、别失焦”

除了语言和框架，这版还有大量 IDE 平台问题。

比如：

• • EEL / IJent APIs 支持 cancellable reads；
• • Project open 不应被 unreachable Eel descriptor 阻塞；
• • dynamic plugins support 重新实现；
• • 更新插件后可能 deadlock；
• • workspace model 中 Select Opened File 对 basePath 外文件无效；
• • Markdown 表格中文格式化不正确；
• • Search Everywhere preview 选择目录后损坏；
• • Tabs 修改文件丢失蓝色文字；
• • Run Widget 长配置名显示不下；
• • Wayland 下 splash screen、tooltip、dialog title bar 的显示问题。

这些点很分散。

但它们背后是同一个主题：IDE 作为一个巨大平台，正在继续修稳定性、远程开发、插件模型和 UI 细节。

尤其是 Remote Development、EEL、插件动态加载，这些都不是单个功能，而是 IDE 未来架构的一部分。

建议动作：

如果你是普通开发者，重点看自己有没有被这些问题影响。

如果你是插件开发者或平台团队，建议重点关注：

1. 1. dynamic plugin support 的变化；
2. 2. PluginClassLoader、bundled plugin、JavaScript/TypeScript 插件依赖问题；
3. 3. DevKit unresolved bundle names；
4. 4. ModCommand 和 PolicyDecorator 相关异常。

一句话总结：IDE 越像平台，稳定性修复就越像基础设施升级。

一张表：不同人该不该升级？

图 2：是否升级 IDEA 2026.2 EAP 4 的决策流程

最后：这版真正值得看的，不是“新功能数量”

很多人看 EAP，只看有没有大功能。

但对 IDE 来说，大量真正影响体验的更新，往往藏在这些不起眼的条目里：

• • 某个正确 HQL 不再被标红；
• • 某个配置类终于能跳转；
• • 控制台大量输出时不再卡死；
• • Kotlin quick fix 不再给奇怪建议；
• • 插件更新后不再 deadlock；
• • Search Everywhere 不再预览崩坏。

这些都不是发布会上会重点讲的东西。

但它们会影响你每天写代码的顺滑程度。

所以，如果你问我 IDEA 2026.2 EAP 4 值不值得看，我的答案是：

如果你等的是大功能，可以先不用急。

如果你正在被 IDE 误报、卡顿、跳转失败、插件问题困扰，这版值得开一个独立环境试试。

从今天开始，你可以先做一件事：

不要直接替换主力 IDE。

先用 Toolbox 或独立安装方式开一个 EAP 环境，导入你的真实项目，验证上面这 8 个方向。

尤其是 HQL、Spring 配置、Kotlin K2、Gradle 同步和测试控制台。

如果这些痛点刚好命中你，这版 EAP 的价值就不小。

如果没有命中，那也没关系。

把它当作 2026.2 正式版前的一次路线观察就够了。

欢迎在评论区聊聊：你最关心 IDEA 哪类更新？是 Java/Kotlin 语言支持，还是 Spring、Gradle、调试器和插件稳定性？

今天的分享就到这里。后续我会持续为大家带来实用的技术干货和前沿的技术资讯。如果你对工具链探索感兴趣，我会持续分享前端工程化、构建优化等实战经验，欢迎关注，不要错过任何精彩内容！