性能税：为什么开发者正在离开 JetBrains 转而使用轻量级编辑器

对于许多开发者来说，选择集成开发环境 (IDE) 不仅仅是一种偏好——它是日常工作流中至关重要的一部分。多年来，JetBrains 一直是专业开发的金标准，提供了一套全面的工具，涵盖了从深度静态分析到复杂的调试等方方面面。

然而，开发者社区中日益增长的一种情绪表明，“全能型”方法正开始遭遇瓶颈。随着高性能、轻量级编辑器与重量级 IDE 之间的差距不断扩大，许多人发现，等待启动画面或重新索引周期的认知成本已不再值得其功能集。

这种转变在 Hacker News 最近的一次热门讨论中得到了体现，一名开发者详细描述了他们为了转向新的 Zed 编辑器而与 JetBrains “分手”的过程。

"重量级"工具的摩擦感

离开 JetBrains 的开发者所提到的主要不满并非功能匮乏，而是性能开销。当一个工具被设计为“万能”解决方案时，它往往会携带一种资源税，从而破坏程序员的“心流”状态。

常见的痛点包括：

• 启动与项目加载： “糟糕透顶”的启动时间和启动画面可能会在开始工作时造成心理障碍。
• 索引疲劳： 对代码库进行持续且往往不透明的重新索引，会占用大量 CPU 核心并拖慢整个系统。
• UI 迟滞： 即使在现代硬件上，简单的任务（如创建新文件或查看建议框）也可能感觉有延迟。
• 资源消耗： 高 RAM 使用量和内存泄漏，导致必须每天重启 IDE。

一位使用高端配置（Ryzen 9950x, 64GB RAM）的开发者指出，即使拥有顶级硬件，WebStorm 仍然“慢得令人痛苦”，在进行 git commits 时进行代码分析需要数分钟，而 TypeScript 错误刷新则需要长达 30 秒。

"快速优先"编辑器的崛起

相比之下，像 Zed、Helix 和 Neovim 这样的编辑器正通过优先考虑响应速度而获得关注。其目标是消除思维与屏幕显示之间的差距。

"一瞬间，我还在终端里愉快地工作。下一秒，我正看着一个功能齐全、拥有我所需的所有工具的编辑器。这就是性能基准，也是期望值。"

这种“即时启动”的体验正在成为新的基准。对于经常在项目之间切换或依赖以终端为中心的工作流的开发者来说，能够在秒级内打开项目是一种变革性的生产力提升。这促使一些人采用了“混合”方法：使用轻量级编辑器处理大部分工作，仅在特定的、复杂的调试任务中保留使用重量级 IDE。

AI 集成冲突

除了性能之外，在如何将 AI 集成到开发体验中，也存在着日益增长的紧张关系。虽然 AI 助手很强大，但许多开发者发现 JetBrains 产品中目前的实现方式过于侵入性。

批评者认为，AI 建议往往会弄乱 UI 或打断打字流，有些人将其描述为“令人讨厌”或“品味欠佳”。开发者们显然希望 AI 成为一种辅助工具——一种可以通过侧边栏或连接器访问的工具——而不是一种将建议强行推到代码行中间的破坏性力量。

反方观点：真正 IDE 的价值

尽管存在挫折感，许多开发者仍然忠于 JetBrains，认为文本编辑器——无论多快——都无法取代完整的 IDE。工具的深度，特别是调试器以及进行交互式实时堆栈编辑的能力，仍然是巨大的吸引力。

一些用户也建议，可以通过配置来缓解性能问题。调整 JVM 设置、增加分配的 RAM（例如， Xms=4g），并使用 ZGC (Z Garbage Collector) 可以显著提高环境的响应速度。对于这些用户来说，为集成工具集的巨大威力而付出几秒钟加载时间的代价是微不足道的。

结论：编辑器的未来

“重型 IDE”与“轻量级编辑器”之间的争论反映了开发者与代码交互方式的更广泛转变。随着语言服务器协议 (LSP) 和 LLM 的兴起，简单文本编辑器与完整 IDE 之间的界限正在变得模糊。

随着开发者越来越优先考虑心流和响应速度，传统 IDE 的压力在于：要么彻底优化其性能，或者面临将用户群流失给新一代工具的层的风险，这些工具将速度视为一等公民功能。