IDEA 2026.2 EAP1到3, 着手修复卡顿现象, 补充内存泄漏问题，并且Agent现在也能够查看调用链了。

最近我把 IDEA 更新到了 2026.2 EAP3。

我留意这个版本, 并非鉴于它又更换了啥界面, 亦或是增添了几个看似颇具智能的按钮。对于长期从事 Java、Boot 以及平台项目编写之人而言, IDE 实际上对体验产生影响之处往往更朴实: 大项目开启之后是否顺畅, 终端会不会吞没输入, 文档撰写篇幅增长后会不会卡顿, 调试以及数据库迁移是否便利, 接入 AI 之后, 究竟仅仅是用于聊天, 还是能够切实领会项目里的调用关系。

就当前所公开呈现的EAP1、EAP2以及EAP3而言, IDEA 2026.2的趋向已然较为明晰: 其一为持续着手处理卡顿、冻结、内存泄漏以及工程稳定性方面的问题；其二是将AI Agent更为深入地融入至IDE已然拥有的代码分析、调试以及项目上下文能力之中。

这里先把版本边界交代清楚。

版本

Build

当前定位

IDEA 2026.2 EAP1

262.4852.50

第一批公开预览构建，集中出现大量基础修复与能力铺垫

IDEA 2026.2 EAP2

262.5752.32

/ 、、MCP 调用链、AI 转换等能力开始更明确落地

IDEA 2026.2 EAP3

262.6228.19

当下可进行体验的版本, 能够去确认, 依赖补全等方面所出现的新增变化, 而更多的能力, 仍旧需要持续进行观察。

EAP 自身并非正式版本, 在 2026.2 开启公告里明确表述为, 这一回会逐渐增添新的 AI、调试、数据库迁移以及语言支持能力, 并非所有规划里的功能都会于最早的几个版本 EAP 中一股脑地呈现出来。

所以, 这篇文章所探讨的并非“2026.2 正式版已然完成了哪些内容”, 而是直至 EAP3 的阶段, 此版本正朝着怎样的方向前行, 有哪些改变已具备值得开发者预先体验的价值。

这次最容易感知到的变化，可能不是 AI，而是卡顿修复

在使用 IDE 时间久了之后, 真正会去烦扰人的, 通常而言并非是缺少某一个快捷功能的情况, 而是一些高频出现的动作, 变得越发拖沓缓慢了。

项目目录展开时出现卡顿现象, 终端输入存在延迟情况, 撰写一份 文档时光标也有延迟, 搜索一个类时突然整个窗口好似没了反应, 各自看似问题不大, 然而叠加在一天的开发节奏当中, 就着实十分磨人。

EAP1 中已经出现了一批与日常流畅性直接相关的修复：

场景

EAP1 中出现的修复方向

对日常使用的影响

大型 文档

修复长 文件输入卡顿问题

写技术文档、架构说明、带 的流程文档更容易感知

内置

修复严重输入延迟与异常行为

进行 Git 操作, 执行 Maven 步骤, 或是运行 CLI Agent, 在 IDEA 里头会感觉更舒适。

大型项目树

修复展开大型目录树时 EDT

多模块平台项目打开目录时不容易短暂假死

WSL / 项目索引

修复覆盖率文件类型检测读取大量 XML 导致的性能回退

容器、远程和混合开发环境更重要

输入过程中的检查

修复 拼写检查可能引发的输入冻结

写注释、、 时更加贴近体感

调试视图

修复调试过程中 XML 导致的冻结问题

查看复杂配置或返回结构时少一点阻塞

我现下常常于IDEA里头径直维护技术文档, 像是支付回调、退款流程、Agent调用链这类文档, 其中还会放置流程图。对于这般使用方式, “in big file is laggy”这种修复, 相较于一些看上去很炫的新功能而言更为实在。

自抵达EAP2以来, 修复的界限朝着诸多方面如搜索、Git、本地过往资料以及构成同步的范畴延展，这一进程持续地向前推进着。

场景

EAP2 中的变化

修复由于 VFS 与写动作竞争导致的冻结

Git 状态刷新

修复仓库管理锁竞争导致的线程池耗尽与死锁

Git 后台更新

减少不可取消协程和潜在阻塞任务

Local

修复

l.force 导致的冻结

+ WSL /

进程异常结束时，不再轻易拖死 Proxy

页面

修复 设置页创建时在 UI 线程执行 IO 的问题

这一批进行修复的情况呈现出这样的特性, 那就是, 它们并非必然会使得一次编译在直接的速度提升上快出多少秒, 然而特别有可能让 IDE 在日常的使用过程当中稍微减少一些显得突兀的卡顿现象。

特别是针对规模较大的 Boot 平台项目而言, 搜索这一行为, Git 刷新这一操作, 同步这一事项, 目录树展开这一动作, 以及文档编辑这一过程, 原本就是在一天当中会反复出现的行为表现。它们进行得较为顺畅一些, 开发者对于版本升级所产生的感受, 相较于某个单独的新特性而言, 反而会更加显著。

然而, 也不能够依据修了诸多的情况, 就径直讲2026.2已然全方位地比2026.1更具速度优势。EAP在一定程度上更像是在逐个地清理具体的阻碍点, 而真实的整体感受, 依旧与项目的规模, 插件的数目, 运行时的版本, 索引的状态以及你实际运用的功能息息相关。

内存占用：不是宣布“更省内存”，而是在堵住越用越高的漏洞

众多开发者在意IDEA的内存情况, 所关注的常常是刚启动之际占据了几个G。

虽说这个指标存有一定的参考价值, 然而对于那些长期开启 IDE 的人来讲, 更为难受的实则是另外一种情形: 起初刚打开的时候尚算正常, 可要是使用了半天时间之后就会变得越来越重；在关闭了项目、切换了文档以及停止了调试操作之后, 内存却长时间都不会回落有标点符号。

EAP1 中能看到多项具体的内存泄漏修复：

问题

意味着什么

泄漏 实例

某些 UI 状态可能持续持有已经不用的项目对象

Inlay Hints 导致 泄漏

内联提示功能可能影响项目关闭后的内存释放

快速切换断点可能触发异常和内存泄漏

长时间调试时容易累积无效对象

大量测试日志不应导致 OOME

极端日志输出场景下减少内存溢出风险

Bazel 初始化期间 OOM

特定构建环境下的内存稳定性修复

EAP2 进一步补充诊断以及内存分析能力, 像是 HProf 打开显著变慢这一问题得到处理, 低内存和 OOM 提示变得更为醒目, 自动错误上报开启后, IDE 能够提交内存报告与未完成的, 另外还有 UI 树组件保留历史版本致使内存滞留的问题。

这些变化表明, 存在着正在切实处理资源消耗的情况, 然而对于这个地方而言, 是不能够阐述得过于详尽充分的。

当前, 并未见到官方公布那种统一基准, 以此来证实, 2026.2 EAP的启动占用相较于2026.1明确下降了多少, 并且, 也没法讲所有项目在EAP3的情况下都会显著更节省内存。更为稳妥的判断是:

2026.存在一批泄漏和冻结问题, 这些问题有可能致使IDE在长时间使用之后变得越来越卡, 当前正在对其展开修复工作, 如此一来，长期驻留体验便有机会趋向稳定；而关于你自身的项目究竟能够降低多少内存, 这还需要进行实际的对比才行。

假如你自身平素就常常同时把后端平台打开, 将前端管理端予以开启, 也打开数据库工具, 还打开技术文档, 更兼带着 AI 插件以及浏览器, 那么内存这儿, 真的最好不要单单只瞧一眼刚开始开机的彼时那一瞬间。当开启项目, 达成索引, 写上一阵子代码, 开展一回调试, 启用 AI 工具之后, 内存能否维持稳定, 这才更贴近于真实的工作状态呀。

关于AI方向, 其中最大的变化是, Agent开始运用IDE的工程理解能力。

这轮版本最有想象空间的部分，确实来自 AI。

可是它的价值并非是再增添一个聊天面板, 在编写代码之际, 模型能够补充几段实现这已然算不上稀罕, 更为困难的是, 其究竟能不能切实领会当下项目的调用关系, 是不是能够真正认知调试现场, 可不可以真正明白模块依赖, 以及能不能确切知晓数据库迁移, 而并非是借助文本搜索在代码堆里去碰运气。

为 2026.2 规划的 AI 方向包括：

方向

想解决的问题

Skill / Skill

让 Agent 在 IDE 内复用经过管理的技能和规范

Next Edit 改进

更准确预测开发者下一步会修改什么

AI- Full

调用一个不存在的方法时，不只生成空壳，还能生成完整实现

MCP 暴露更多 IDE 能力

让 Agent 看到调试器、断点、 等真实工程上下文

CLI Agent 支持

在终端当中, 当与 Agent 展开配合之际, 可以直接进行 文件的拖动操作, 能够粘贴图片, 并且能够使用项目 JDK。

新增的能力

这些属于整个二零二六点二周期的推进方向, 并非意味着在EAP3里已然全部开放, 是这样的情况, 没错吧。

于 EAP1、EAP2 变更列表之中, 切实能够看见的那些得以落地的相关内容, 主要聚焦于 MCP 连接底座以及 AI 辅助转换这两方面了！

在 EAP1 里, IDEA 着手重新构建 MCP 客户端自动配置能力, 去处理现代 HTTP 的兼容难题, 转而采用新的命令来启动 MCP, 能够自动配置 Junie, 并且修复与 /Code 相关的接入问题。另外存在一项测试任务, 这表明 Agent 与调试器之间的连接已然在进行铺垫工作。

到了 EAP2，一个对实际项目分析更有价值的能力出现了：

MCP 新增 Call 工具。

这件事对 Java 开发者很重要。

举例来说, 此刻我正在对一条微信支付回调链路进行梳理, 在代码当中, 大概会存在这样的路径:

PayController.payNotify(...)
    -> WxPayService.notify(...)
    -> handlePayResult(...)
    -> dispatchPayHook(...)

以往将这个问题交付给 Agent, 它极有可能仅仅是搜寻 、、 这些字符串, 接着依据文件内容来揣摩调用链。当代码较为简易之时还算能够满足需求, 然而涉及到接口实现、重载、分支以及异步任务往后就容易出现偏差。

要是 Agent 能够借由 MCP 去运用 IDEA 的 Call , 那它所获取到的并非仅仅是若干相匹配的文本, 而是 IDE 已然解析出来的调用关系。如此这般做事代码走查、生成流程文档、分析状态流转, 可靠性便会提升到一个更高层级。

EAP2 当中还涵盖了这样一些变化, 将 MCP 搜索结果结构简化成行列坐标, 有修复工具输出, 减少 MCP 控制调试会话时 UI 抢焦点。这些变化听起来不像“AI 生成完整代码”那样吸引眼球, 然而却是切实决定 Agent 能否稳稳接入 IDE 的底层工作呢。

与此同时, 由Java转换而来的AI能力正处于提升状态。EAP1修正了多文件转换里后续文件建议出现异常的状况 ；自从EAP2起始, 便纳入了审核合格的J2K　AI , 并且对多文件AI - J2K予以支援。

对于纯Java项目而言, 此项功能并非那种必须当下就予以使用的功能。然而, 要是团队存在Java代码迁移方面的需求, 那么它起码已经开启了迈向真实模块迁移的进程, 这一进程起始于“先对单文件进行尝试”。

数据库迁移：这类功能不热闹，但项目里很值钱

如果只盯着 AIintellij idea gradle，这轮版本里还有一块很容易被忽略： 和 。

EAP1 已然着手改进故障处理体验, 其中涵盖在迁移文件里呈现更为具体的异常详细情况, 并且还支持从失败日志跳转至相应的失败文件。

EAP2 又进一步加入：

功能

价值

Run

把迁移执行纳入固定运行配置

改为 Run

数据库升级操作更容易复用和管理

Diff 生成

差异脚本执行前的约束表达更完整

此类能力于平常的demo项目之中显现的存在感觉并不强烈, 然而一旦真正到了平台系统里面, 情况就会变得有所不同了。

打个比方, 存在一个低代码的平台, 或者是AI平台, 后续会渐渐增添租户、关于组织的信息、模型供应商、API Key、用量的统计情况、费用的结算方式、工具调用的日志记录、知识库、评测的记录等诸多表结构。有谁在本地手动修改了一回字段, 有谁在测试环境补充了一条索引, 有谁在发布的时候遗漏运行了一份脚本, 随着时间慢慢过去, 都极有可能演变成难以查找的数据方面的问题。

数据库迁移进入IDEA的统一运行配置后, 至少能使这件事更趋近于正式工程流程, 而非临时SQL操作。AI以后即便能够协助生成迁移脚本, 真正执行至哪个库、变更能否回滚、失败后怎样定位, 依旧需要这样的工具链兜底。

也在增强，但 EAP 里的插件兼容问题依旧要防

现在, 我愈发倾向于运用IDEA直接对文档予以维护, 原因在于技术设计文档与代码原本就距离甚近。支付回调流程、数据库结构、Agent架构、接口调用时序, 诸如此类的内容倘若能够于项目之中与源码一并进行维护, 相较于散落于外部工具里, 会更易于实现持续更新。

EAP1 将大型文件输入途中出现的卡顿状况予以修复处理, 而 EAP2 通过增添的方式, 加入了一批针对技术文档而言更为适配的能力。

功能

使用场景

反引号中的符号支持导航

文档里写 . 时更容易关联源码

从选中文字创建链接

写设计文档和 Blog 时更方便

支持链接中的行号片段

代码走查文档可以更精准引用位置

从项目根目录运行

文档命令执行路径更统一

这部分跟我当下实际运用的情况很是贴近。然而, 在升级至EAP3之后, 我也遭遇了一个颇为典型的EAP小问题: 在写 图的时候, 运用 并不能让图形正常显示出来；要切换到浏览器类预览引擎, 再搭配 插件之后图形才恢复到正常显示状态。

另外, 流程图里的节点文字, 要是含有类似 /pay/{pid}/{orgId}/{scId} 这样的路径参数, 花括号就会被当作流程图语法, 必须把节点文字写在双引号当中, 才能经过解析。

这并不是在表达EAP3不能够被使用, 而是能够非常有说服力地表明EAP的真实状况, 在其出现变化后, 存在着这样的情形, 即一方面有些高频体验的确是变得更好了, 然而另一方面一些新链路以及插件组合依旧有可能需要自身去进行一番迂回绕路操作。

与 ：平台开发日常会用到的增量

在EAP1里, 方向的变化主要集中于配置属性, 在EAP2中, 方向的变化主要集中于测试配置, 方向的变化还集中于路径变量提示, 方向的变化也集中于运行时调试相关修复。

诸如, 补全Boot配置属性, 针对缺少@ies前缀给出quick fix, 识别测试注解里的引用，还有给出关于MVC路径变量的修复劝告, 这些个, 全都是天天会遇上, 然而极少有人专门撰写一篇文章予以述说的小增进。

针对于 Boot 项目而言, 其价值体现于削减一些虽低级却耗费时间的错误, 特别是在配置文件日益增多, 以及测试环境与生产环境参数愈发复杂之后, IDE 能够尽早将错误显露出来, 这通常要比上线之后再去查看日志舒坦许多。

一方面, EAP1 对 API 9.4 进行了跟进, EAP2 则对 API 9.5 展开了跟进, 同时还处理了 WSL / 场景之下的同步稳定性问题。另外, EAP3 当前能够确认的一项新变化, 乃是依赖字符串中的自动补全能力开始显现出来。

比如在 build..kts 中写：

dependencies {
    implementation("org.springframework.boot:")
}

或者后续试用 AI 时写：

dependencies {
    implementation("org.springframework.ai:")
}

要是 IDE 可以于真正所需的地方给出更为精准的坐标以及版本候选, 那么体验将会比在构建脚本当中毫无边际地弹出提示要更让人舒适。

Java 27、 、完整方法生成intellij idea gradle，现在还不要写成已经到手

在 2026.2 的方向公告里还提到了几项很诱人的内容：

这些能力均值得予以关注, 特别是 Java 27, 以及 MCP 调试能力, 其与 Java、AI、企业系统开发之间的关系十分紧密。

在到达EAP3的这个阶段之前, 不能仅仅因为公告中写明了“正在对其进行操作”, 便径直将它们视作当下版本已然完整交付的职能。当开发者切实进行使用之际, 依旧需要以在本地能否寻觅到入口, 以及功能是否稳定可正常使用作为判断的标准。

必须守住这种边界, EAP 的价值在于提前尝鲜以及参与反馈, 并非是让人把路线图提前当作正式版功能清单。

EAP3 值不值得尝试？

要是你仅仅是想拥有一个用于稳定工作的主力集成开发环境, 而不愿意去应对插件兼容性、预览引擎、偶尔出现的回退以及实验性功能的不确定性状况, 那么此刻持续使用2026.1正式版本会更加稳定。

倘若你自身正从事Java项目, 或是Boot项目, 又或是AI Agent项目, 再或是数据库迁移项目, 2026.2 EAP3已然值得专门去安装一份来体验一番。

我所提出的建议是, 使用的方式并非是“将正式版直接进行覆盖”, 而是借助App, 以并行的形式, 保留两个版本。

使用场景

建议版本

日常关键项目开发、准备发布、线上紧急修复

2026.1 正式版

体验 、、MCP、 / 、 新补全

2026.2 EAP3

测试 AI Agent 能否读取调用链、协助排查代码

2026.2 EAP3

验证插件兼容性与新调试体验

2026.2 EAP3

对我来讲, EAP3 里头, 最值得去尝试一番的, 并非那些尚未全方位落地现身的“重大举措”, 而是已经与日常开发相当靠近贴近甚至有所融合渗透的几件变化之处, 这些变化存在于EAP3里:

此时正在于IDEA 2026.2做的各项事情, 事实上特别神似当下的开发环境自身, 先是AI会越发频繁地进到编码环节、分析环节以及调试现场, 然而, 真正能够稳住项目走向交付终点的, 依旧是那些像是性能、稳定性、调用链、数据库迁移以及调试能力这般看起来并不张扬喧闹的工程基础架构部分。

升级一个 IDE 值不值, 这一结果并非取决于它所拥有的 AI 名词数量, 而是在你运用它编写一天代码之后, 卡顿的现象是否有所减少, 问题是否能更简便地查明白, Agent 进入项目后是否变得更为可信。

ps: 测试用了一天感觉挺好，感兴趣的小伙伴也可以试一试。

参考资料

如有侵权请联系删除！