IntelliJ IDEA 2026.2 EAP 2 来了：开发者最该关注的 8 个变化清单

每次 IntelliJ IDEA 的 EAP 版本更新，我都会先做一件事：

不是立刻安装。

而是先扫 Release Notes。

因为 EAP 版本最有价值的地方，往往不在一个特别显眼的新按钮上，而是藏在一堆看起来很碎的条目里：构建工具、补全、调试器、Spring 配置、Kotlin K2、Remote Development、Markdown、插件系统……

如果你一条条读，很容易读到后面就忘了前面。

但如果换一种方式，把它拆成“开发者每天会遇到的问题”，就清楚很多：

• • Gradle / Maven 项目导入会不会更稳？
• • Java 补全、调试、inspection 有没有少一点误报？
• • Kotlin K2 迁移是不是继续推进？
• • Spring Boot 配置能不能更聪明？
• • Flyway / Liquibase 迁移脚本能不能更好跑？
• • Markdown 文档写作体验有没有改善？
• • WSL / Docker / Remote Dev 会不会少卡一点？
• • MCP、插件、诊断、日志这些平台底座有没有继续补强？

所以这篇不逐条翻译 Release Notes。

我把 IntelliJ IDEA 2026.2 EAP 2 里最值得开发者关注的变化，整理成 8 个方向。

你可以把它当成一份升级前检查清单。

先给结论：这次 EAP 2 值得看什么？

如果只用一句话概括：

IntelliJ IDEA 2026.2 EAP 2 的重点，是继续把日常开发链路里的“卡点、误报、兼容性和远程场景”往前补。

这次比较值得关注的有 8 类：

1. 1. Gradle / Maven 继续补现代构建场景，尤其是 Gradle 9.5.0、WSL、Maven Toolchains。
2. 2. Java 补全、调试、inspection 都在修边角问题，命令补全也开始加入更多“解释”和“预览”能力。
3. 3. Kotlin K2 仍然是重点，quick fix、inspection、completion、J2K 都在继续迁移和打磨。
4. 4. Spring Boot 配置识别继续增强，Map、List、POJO、自定义属性这些老痛点都被点名。
5. 5. Flyway / Liquibase 开始更偏“运行配置化”，数据库迁移操作会更贴近日常工作流。
6. 6. Markdown 体验集中修复，从预览、表格、链接、锚点到 backticks 引用导航都有动作。
7. 7. Remote Development、WSL、Docker、Terminal 继续加固，远程开发已经是主线能力。
8. 8. 平台底座继续为 MCP、插件模型、诊断、Search Everywhere、VCS 性能铺路。

下面逐条展开。

1. 构建工具：Gradle 9.5.0、WSL、Maven Toolchains 是重点

这次 Build 相关条目不算多，但都很贴近日常项目。

Gradle 方向最值得看的是：

• • 使用 Gradle Tooling API 9.5.0。
• • 将 Gradle 9.5.0 加入 compatibility matrix。
• • 修复 WSL 下启用 Android plugin 时 Gradle sync 不工作。
• • 修复 Gradle 9.5.0 + WSL 场景下“成功同步却显示失败”的问题。
• • 修复 WSL / Docker 下 Gradle 进程异常终止后 Tooling Proxy 可能冻结的问题。

Maven 方向则出现了一个很关键的 Meta Issue：

• • Support Maven Toolchains。

这说明 IDEA 2026.2 EAP 2 对构建系统的关注点，不是“多支持一个按钮”，而是更贴近真实团队项目。

真实项目里，构建工具最烦的不是语法问题，而是环境差异：

• • 本机和 WSL 表现不一致。
• • Docker 里跑和本地跑表现不一致。
• • Gradle 版本升级后 IDE compatibility matrix 跟不上。
• • Maven Toolchains 配了，但 IDE 不能完整理解。
• • sync 成功了，界面却告诉你失败。

这类问题很磨人。

因为它会让开发者陷入一种很尴尬的状态：命令行看起来正常，IDE 里却红一片。

构建工具的体验，决定了你打开项目后的第一印象。

如果你维护 Gradle / Maven 多模块项目，尤其是带 WSL、Docker、Android plugin 或多 JDK toolchain 的项目，这次 EAP 2 值得重点验证项目导入和同步。

2. Java：补全、调试、inspection 都在补“日常小坑”

Java 相关条目这次分布很广。

比较值得关注的有几组。

第一组是代码补全：

• • 修复补全在启用“按空格、点号等上下文键插入建议”时可能多插入字符的问题。
• • custom inspection 作为 command completion 的一部分时不工作的问题被点名。
• • 支持在 live templates 的 mod-completion 里使用 foreach。
• • command completion 的 Write documentation action 增加 preview。
• • command completion 增加 explain regexp。

这说明 IDEA 的补全能力正在从“给候选项”走向“能解释、能预览、能嵌入命令式操作”。

第二组是调试器：

• • Evaluate code 遇到 lambda 编译失败的问题。
• • 实现 combined conditional and logging breakpoints。
• • HotSwap 后 frame 被标记 obsolete、断点行不高亮的问题。
• • 添加带条件断点时偶发 VerifyError。

调试器这些问题看起来都很细，但对日常开发影响很直接。

尤其是 combined conditional and logging breakpoints。

条件断点和日志断点如果能更顺手，就可以减少“为了看一个变量加一堆临时 log”的情况。

第三组是 inspection 和错误高亮：

• • nested switch expressions 误报 Ambiguous method call。
• • for-loop initialization block 多语句被错误报语法问题。
• • JSpecify / @NullMarked 相关 false positive。
• • import 被标记 unused 但 optimize 不掉。
• • diamond operator 在 @NullMarked 场景下 type inference 不正确。

这些变化背后的重点是：

IDEA 正在继续降低现代 Java 项目里的误报成本。

现在 Java 项目不再只是“写 class、写 method”。

它还会混合：JSpecify、nullability、annotation、lambda、switch expression、external annotation、compiled jar、command completion。

IDE 如果理解不准，开发者就会被误报打断。

所以这次 Java 部分最值得验证的，不是有没有新语法高亮，而是你的项目里旧误报有没有减少、新误报有没有出现。

3. Kotlin：K2、inspection、J2K 还在继续收口

Kotlin 部分依然很密集。

这次能看到几个明显方向。

第一，K2 inspection 和 quick fix 继续迁移：

• • Port KotlinInternalInJavaInspection。
• • Port KotlinJvmAnnotationInJavaInspection。
• • K2: Redundant OptIn inspection。
• • K2 IDE: Port OptInFileLevelFixesFactory。
• • K2: Port SimplifyNestedEachInScopeFunctionInspection。
• • K2: Port SwapStringEqualsIgnoreCaseIntention。

第二，日常 coding 的 false positive 继续修：

• • Kotlin DSL builders 里错误调用被误高亮。
• • explicit context arguments 场景下参数名提示误报。
• • Compose WASM 中 @Composable 调用被误报 ARGUMENT_TYPE_MISMATCH。
• • CharArray print/println 被 KotlinArrayToString 误报。
• • KDoc samples unresolved links 被错误标记。

第三，重构和 quick fix 继续补边界：

• • K2 Refactor / Move 后 redundant Companion reference。
• • Extract Function 后 redundant import。
• • Change function signature quick fix 对 varargs 生成错误代码。
• • Named-based destructuring 在 property rename 后没有更新。
• • Find usages 对 named-based destructuring 不工作。
• • Generate equals/hashCode 在已有方法时可能 NPE。

第四，J2K 和 AI 辅助转换开始更明显：

• • Bundle JB approved J2K AI skills。
• • Multi-file AI-assisted J2K conversion。
• • J2K 转换 generic Enum.valueOf 时异常。

这说明一件事：

Kotlin K2 时代的 IDEA，不只是把分析引擎换掉，而是在把补全、检查、重构、J2K 转换这些日常工作流全部重新打磨一遍。

如果你是 Kotlin 用户，这次 EAP 2 建议重点验证 4 件事：

1. 1. K2 模式下 completion 是否稳定。
2. 2. quick fix 会不会生成错误代码。
3. 3. rename / move / extract function 后 import 和引用是否正确。
4. 4. J2K 或多文件 Java 转 Kotlin 转换是否符合预期。

尤其是 KMP、Compose WASM、Spring + Kotlin、Kotlin DSL builders 这些项目，建议专门开测试分支试一下。

4. Spring Boot：配置属性识别继续补老痛点

Spring 相关变化里，最值得普通开发者看的还是 Spring Boot Configuration。

这次被点名的包括：

• • 支持 Spring Boot properties 里的 Map bracket notation。
• • 修复有效代码中误报 Invalid @ConfigurationProperties / Duplicated Prefix。
• • 自定义 properties 中，POJO-type properties 不应强制要求 @NestedConfigurationProperty。
• • List<? extends Map<String,String>> 类型的配置属性无法解析。
• • YAML 中 Map<POJO> 类型配置导航没有考虑 POJO properties。
• • NotRegisteredConfigurationProperties inspection 编辑后误报重新出现。

这些问题非常 Spring。

因为 Spring Boot 项目里的配置，经常不是简单的 key-value。

真实项目里会有：

• • Map。
• • List。
• • 泛型。
• • POJO 嵌套。
• • YAML 多层结构。
• • 自定义 ConfigurationProperties。
• • profile 和测试配置。

IDEA 如果不能正确理解这些结构，就会出现两类问题：

1. 1. 明明配置有效，IDE 报红。
2. 2. 明明配置有问题，IDE 没提醒。

这两类都很烦。

前者让你不信 IDE。

后者让你运行时才踩坑。

这次 EAP 2 的 Spring Boot 配置更新，重点就是减少这类“不信任感”。

Spring Boot 配置不是普通字符串，它应该被 IDE 当成一等代码资产。

如果你维护的是配置比较复杂的 Spring Boot 项目，这次建议重点验证：

• • @ConfigurationProperties 是否还有重复 prefix 误报。
• • Map / List / 泛型属性能不能正常补全和跳转。
• • YAML 里嵌套 POJO 属性能不能导航。
• • 自定义 properties 是否还需要不必要的注解。
• • inspection 是否会在编辑后重新误报。

5. 数据库迁移：Flyway / Liquibase 更像 IDE 工作流的一部分

数据库迁移这次也值得单独拿出来说。

Release Notes 里有 3 个点比较明显：

• • Flyway: add Update run configuration。
• • Liquibase diff doesn't generate preconditions。
• • Liquibase: rewrite Update action to run configuration。

这几个变化的关键词是：run configuration。

过去很多团队跑 Flyway / Liquibase，习惯是在命令行、Gradle task、Maven plugin 或 CI 里处理。

IDE 里能看、能跳转、能提示已经很好。

但如果迁移动作能更自然地接入 Run Configuration，体验会更统一。

因为 Run Configuration 不是一个简单按钮。

它背后包含：

• • 环境变量。
• • 工作目录。
• • profile。
• • JDK。
• • before launch。
• • 日志输出。
• • 运行历史。
• • 团队共享配置。

把 Flyway / Liquibase 的 update 动作放进运行配置里，意味着数据库迁移更容易被纳入 IDE 的日常工作流。

这对后端开发很实用。

尤其是本地联调时，你经常需要做这些事：

• • 切换数据库环境。
• • 跑一遍 migration。
• • 看失败日志。
• • 调整参数后重跑。
• • 和 Spring Boot 启动配置配合。

数据库迁移如果能像启动应用一样被管理，本地开发会顺很多。

如果你项目里用 Flyway 或 Liquibase，这次 EAP 2 建议重点看 Update run configuration 的入口、参数、日志展示和失败定位。

6. Markdown：文档党这次可以重点看

这次 Markdown 相关条目非常多。

而且不是单点修复，是一整组体验问题。

比如：

• • Markdown preview 不渲染项目外图片。
• • 只有一个 --- 开头时无法正确渲染。
• • Enter 在列表项前不应额外留下空列表项。
• • Reformat Markdown File 会拆分 tokens。
• • Markdown table 编辑应忽略 code block 里的 ||。
• • 创建 Todo list 留下双 closing brackets。
• • shell code block 里单词高亮 offset 错误。
• • Markdown table 被误标为格式不正确。
• • Go to declaration 快捷键和格式化快捷键冲突。
• • HTML anchors 出现 cannot resolve anchor warning。
• • reference links 格式化损坏。
• • Surround with live template 在 Markdown 中损坏。

同时还有几个 feature：

• • 支持导航到 Markdown backticks 中引用的 symbols。
• • 从项目根目录运行 Markdown commands。
• • 从选中文本创建链接。
• • 支持 links 中的 line number fragments。

如果你经常在 IDEA 里写 README、技术文档、开发笔记、接口说明，这部分很值得看。

Markdown 的问题通常不致命。

但它很影响心情。

表格格式化错了、锚点误报、链接坏掉、预览不显示图片、Todo list 多括号，这些都不是大 bug，但每天遇到就很烦。

尤其是现在很多开发者会在项目里维护：

• • README。
• • ADR。
• • API 文档。
• • 技术方案。
• • Release Notes。
• • 开发手册。
• • Prompt / AI 工作流说明。

IDEA 的 Markdown 能力越稳，项目文档维护成本越低。

文档体验不是边缘功能，它已经是工程协作的一部分。

7. 远程开发：WSL、Docker、RemDev、Terminal 继续加固

EAP 2 里远程相关内容仍然不少。

可以分成几类看。

WSL / Docker 相关：

• • Gradle sync 在 WSL + Android plugin 场景下不工作。
• • Gradle 9.5.0 在 WSL 下成功 sync 却显示失败。
• • WSL / Docker 下 Gradle process 异常终止不应导致 Tooling Proxy 冻结。
• • DevContainers 中 x86_64 Dev Container on ARM macOS 的 JDK Download dialog 显示无可用 JDK。

Remote Development 相关：

• • Remove Beta label for Remote Development。
• • 实现 restart frontend、backend、both 的 internal actions。
• • Remote IDE 重连后 code completion 不工作。
• • Remote Dev 中 Plugins 错误重复。
• • Remote Dev 中 Update All plugins link 不存在。
• • Terminal 在 RemDev 中启动成本地进程而不是远程进程。
• • TODO tool window 在 RD 中预览和导航修复。

Terminal 相关：

• • tmux 中光标渲染位置错误。
• • 文件路径链接弹窗在双击/三击选择文本时闪烁。
• • folder links 不打开 Project tool window。

这些变化说明一个趋势：

JetBrains 已经不再把远程开发当成补充场景，而是在把它当成主线工作流打磨。

现在很多项目的真实环境就是混合的：

• • macOS 本机写代码。
• • WSL 跑 Linux 工具链。
• • Docker 放依赖服务。
• • Dev Container 固定环境。
• • Remote Development 连接远程机器。
• • Terminal / Git / Gradle / Maven 全部跨环境协作。

只要其中一个环节理解错了，体验就会断。

所以这次 EAP 2 的远程开发部分，建议重点验证：

1. 1. WSL 项目 Gradle sync 是否正常。
2. 2. Docker / Dev Container 中 JDK 下载和项目打开是否正常。
3. 3. Remote IDE 重连后补全是否恢复。
4. 4. Terminal 是否运行在正确环境。
5. 5. 插件更新、TODO、Debugger、Services View 是否还能正常工作。

8. 平台底座：MCP、插件、诊断、Search Everywhere、VCS 性能继续铺路

最后一类变化，普通用户可能不会第一眼注意到，但它非常重要。

先看 MCP：

• • 简化 MCP search result schema 为 line/column coordinates。
• • MCP output schema 中 nested default properties 被错误标记 required。
• • 抑制 MCP-controlled debug sessions 的 debugger UI attraction。
• • MCP 增加 analyze_calls Call Hierarchy tool。
• • DevKit 中 McpTool annotated methods 被显示 unused 的问题。

这说明 JetBrains 仍在为 AI Agent / 工具调用 / IDE 内部能力开放做准备。

再看插件模型和插件管理：

• • Remote Dev 中 Plugins 错误重复。
• • Free mode 中 ultimate-dependent plugins loading 错误通知。
• • 网络错误时 plugin duplicate cache 处理。
• • 不允许插件通过 PluginManagerCore 启用或禁用插件。
• • 插件模块列表存到 runtime module repository。
• • plugin model 解析模块时考虑 namespace。
• • 前端进程中禁用的插件重启后可能重新启用。

插件系统越复杂，IDE 越需要更严格的边界。

这对普通用户的直接影响是：插件冲突、插件误报、插件远程加载问题会逐步减少。

再看诊断：

• • EAP builds 中 idea.log exception auto-reporting 不工作。
• • OOM 和 low memory notifications 使用更合适的提示方式。
• • telemetry JSON 移到 telemetry dir。
• • Help | Collect logs action 静默失败。
• • 自动错误报告开启时提交 memory reports。
• • 自动报告 unfinished freeze reports。

这类变化看起来“不性感”，但非常关键。

EAP 阶段最重要的事情之一，就是发现问题后能收集证据、能自动上报、能帮助官方定位。

还有 Search Everywhere、VCS、Local History 等性能问题：

• • Search Everywhere freeze caused by VFS-refresh write-action contention。
• • Git VcsRepositoryManager lock contention 导致 deadlock。
• • GitRecentCommitsProvider 每次仓库更新调度阻塞协程。
• • Local History 中 ChangeListStorageImpl.force freeze。
• • Save local history data on background thread。

这说明 IDEA 仍在治理大项目里的“冻结”和“卡顿”。

平台底座的意义，就是让你感觉不到它存在。

如果你是插件开发者、AI 工具用户、Remote Dev 用户，或者维护大型 monorepo，这部分值得重点关注。

升级前检查清单：你应该重点验证什么？

【正文插图 2：IDEA 2026.2 EAP 2 升级验证清单】 建议插入位置：本节前。 源文件：images/illustrations/source/idea-2026.2-eap2-upgrade-checklist.drawio

如果你想试 IntelliJ IDEA 2026.2 EAP 2，不建议只打开项目看一眼。

可以按下面这份清单验证。

Gradle / Maven 项目

• • 验证 Gradle 9.5.0 项目导入、sync、reload 是否正常。
• • WSL / Docker 环境下重点看 sync 成功状态是否准确。
• • Maven 项目重点看 Toolchains 是否能被 IDE 正确理解。
• • 多模块项目验证依赖解析、测试运行和运行配置。

Java 项目

• • 试 command completion 的文档预览和 explain regexp。
• • 验证补全是否还会多插入字符。
• • 检查 JSpecify / @NullMarked / diamond / switch expression 相关误报。
• • 调试时重点看 lambda evaluate、条件断点、日志断点、HotSwap。

Kotlin 项目

• • K2 模式下验证 inspection、quick fix、completion。
• • 重点看 rename、move、extract function 后 import 和引用是否正确。
• • Compose WASM、KMP、Spring + Kotlin 项目重点看误报。
• • 试多文件 AI-assisted J2K conversion 是否符合预期。

Spring Boot 项目

• • 检查 @ConfigurationProperties 是否还有重复 prefix 误报。
• • 验证 Map / List / 泛型配置属性的补全、跳转和导航。
• • YAML 中 Map<POJO> 类型配置能否正确识别。
• • 编辑配置后看 inspection 是否重新误报。

Flyway / Liquibase

• • 查看 Flyway Update run configuration 是否可用。
• • 验证 Liquibase Update action 的 run configuration 化体验。
• • 跑一次本地迁移，看日志、失败定位和参数配置是否顺手。

Markdown 文档

• • 打开 README 或技术方案，验证预览、表格、链接、锚点。
• • 测试 backticks 中 symbol navigation。
• • 测试从选中文本创建链接。
• • 验证 Markdown commands 是否从项目根目录运行。

远程开发 / WSL / Docker

• • 验证 WSL 下 Gradle sync 和状态展示。
• • 验证 Dev Container 中 JDK 下载和项目打开。
• • Remote IDE 重连后测试补全、Terminal、TODO、Plugins。
• • tmux、路径链接、folder links 这些 Terminal 细节也可以顺手看。

平台与性能

• • Search Everywhere 是否还出现卡顿。
• • Git / Local History 在大项目里是否有明显 freeze。
• • Help | Collect logs 是否能正常收集日志。
• • MCP / 插件用户重点看工具调用、插件加载和日志噪音。

最后：EAP 2 不是“换皮更新”，而是在补完整开发链路

如果你期待 IntelliJ IDEA 2026.2 EAP 2 带来一个特别炫的新界面，可能会觉得它不够刺激。

但如果你每天都在 IDEA 里写 Java、Kotlin、Spring，跑 Gradle / Maven，维护 Markdown 文档，连 WSL / Docker / Remote Dev，再加上一堆插件和 AI 工具，你会发现这次更新非常实际。

它修的不是一个孤立按钮。

而是完整开发链路：

• • 项目导入。
• • 代码补全。
• • 调试断点。
• • 静态检查。
• • Kotlin K2。
• • Spring 配置。
• • 数据库迁移。
• • 文档维护。
• • 远程开发。
• • 插件和诊断。
• • 大项目性能。

这些东西不一定适合做发布会标题。

但它们决定了你一天写代码时，是顺着走，还是一直被 IDE 打断。

我的建议是：

如果你是主力开发环境，不建议直接把 EAP 当生产版本用。

但如果你维护的是 Java / Kotlin / Spring 大项目，或者你正在使用 WSL、Docker、Remote Development、MCP、AI-assisted J2K 这些能力，2026.2 EAP 2 值得开一个测试环境体验。

先不要问“有没有大功能”。

先问一个更实际的问题：

它有没有把你每天最烦的那些小问题，少修掉几个？

如果答案是有，那这次 EAP 2 就值得关注。