前几个月，我表弟——一个刚入行的Android开发新手——在微信上问我：“哥，为啥公司里大佬都用IntelliJ IDEA，但我看B站教程都在用VS Code？我到底该学哪个？”

我没直接回答，而是给他讲了个故事。

三年前，我同时开着IDEA和VS Code工作：IDEA用来写java/Kotlin后端，VS Code用来改Kotlin DSL脚本和看文档。两个窗口来回切换，Alt+Tab按得手指都快抽筋了。那时候我就想：要是VS Code能像IDEA一样懂Kotlin该多好。

没想到，2026年5月，JetBrains真的把这个"妄想"变成了现实。

一个"自我背叛"的决定

在KotlinConf 2026上，JetBrains扔出了一个让很多人意外的炸弹：官方Kotlin扩展正式登陆VS Code

等等，我没说错吧？JetBrains？那个靠卖IDE许可证活得好好的JetBrains？给VS Code——这个免费、轻量、市场份额碾压一切的"敌人"——开发官方插件？

初看确实有点魔幻。但仔细想想，这步棋背后藏着JetBrains对Kotlin生态的深层思考。

先看看这个插件能提供啥：

• IDEA级别的智能代码补全（不是那种关键字提示，而是真正的类型感知补全）
• 实时错误诊断（写错代码立马标红，不用等编译）
• 代码导航（跳转定义、查找引用）
• 快速修复（Alt+Enter拯救你的代码）
• 自动格式化（Kotlin代码风格统一）
• 项目导入（Gradle项目一键加载）

听起来是不是很像IDEA的基础功能？没错，因为这玩意的核心就是Kotlin Language Server——一个基于IntelliJ IDEA代码洞察基础设施构建的语言服务器。也许是第一次因为kotlin的原因让VS Code用户也能体验一把IDEA编码效率

为什么"叛变"？

1. 市场份额的残酷现实：打不过就加入

数据不会撒谎：截至2026年，VS Code占据了73%的开发者的首选编辑器位置。在某些领域（比如前端、数据科学、轻量级脚本），这个比例甚至更高。

JetBrains面临一个尴尬的局面：

• 坚持只做IDEA？那意味着放弃大量VS Code用户，Kotlin的使用场景会被限制。
• 适配VS Code？看似"资敌"，但实际上扩大了Kotlin的生存空间。

这就像当年微软开源.NET一样：当你的技术足够优秀，但平台不够大时，是守着围墙花园，还是走出去拥抱世界？

“工具的价值不在于工具本身，而在于它服务了多少开发者。”

2. 生态战略：Kotlin的敌人不是VS Code，而是Java、Python、Go

这里有个认知陷阱：很多人认为JetBrains的竞争对手是微软（VS Code的东家）。但站在Kotlin语言的角度，真正的竞争对手是其他编程语言。

想想看：

• 后端领域：Java（Spring）、Go、Rust都在抢市场份额
• 前端领域：TypeScript/JavaScript占据绝对优势
• 移动端：Swift（iOS）和Kotlin（Android）分庭抗礼，但跨平台框架（Flutter/Dart、React Native/JavaScript）虎视眈眈

如果Kotlin只能在IDEA里舒服地写，而在VS Code里体验拉胯，那很多开发者会怎么选？答案很明显：直接用VS Code原生支持更好的语言。

所以，JetBrains这步棋的本质是：降低Kotlin的使用门槛，让它在任何编辑器里都有一战之力。

3. 用户行为的真相：开发者从来不是"单一IDE用户"

我观察过身边的开发团队，发现一个有趣的现象：

即使是IDEA的死忠粉，也会在以下场景打开VS Code：

• 快速查看配置文件（YAML、JSON、Markdown）
• 写一些简单的脚本（Shell、Python、JavaScript）
• 参与多语言项目（前端用VS Code，后端用IDEA）
• 远程开发（VS Code的Remote SSH体验确实香）

2026年的开发趋势显示，多IDE并存已经成为常态。VS Code凭借轻量级和AI扩展性（如Copilot），成为代码生成和快速验证的首选；而JetBrains IDE则专注于深度代码理解和重构

JetBrains官方也承认：“IntelliJ IDEA和Android Studio仍然是最完整的Kotlin开发环境，但不是每个Kotlin开发者每天都在那里工作。有些开发者更喜欢VS Code，或者已经将其作为工作环境的一部分。”

与其让用户在VS Code里忍受糟糕的Kotlin体验，不如主动提供官方支持。

4. 技术架构的优雅：LSP让"双赢"成为可能

这里涉及到一个关键技术：Language Server Protocol（LSP，语言服务器协议）。

简单说，LSP把"语言智能"（代码补全、跳转、诊断）从编辑器里抽离出来，变成一个独立的服务。编辑器只需要实现LSP客户端，就能获得语言支持。

这个架构的精妙之处在于：

• JetBrains不需要重写一套语言服务，直接复用IntelliJ多年积累的代码洞察能力
• VS Code获得企业级Kotlin支持，用户体验大幅提升
• 其他编辑器（如Zed、cursor、Neovim）也能受益，只要它们支持LSP

这不是"资敌"，这是技术输出的高级玩法。

5. 商业模式的进化：从卖工具到卖生态

2026年，JetBrains已经意识到一个现实：单纯靠卖IDE许可证的增长空间有限。

看看他们的动作：

• 推出Fleet（轻量级编辑器，直接对标VS Code）
• 为VS Code开发官方扩展（Kotlin、Java转Kotlin转换器）[[1]]
• 探索AI编程助手与传统IDE的结合[[8]]

这背后是一个战略转变：从"卖工具"转向"经营生态"。

Kotlin的成功，会带动JetBrains IDE的销售（因为IDEA确实提供了更完整的体验）。但前提是，Kotlin本身要足够流行。而流行的前提，是在任何地方都能舒服地使用Kotlin。

这就像Google开源Android：看似放弃了控制权，实际上通过生态占据了移动操作系统的主导地位。

技术细节：这个插件到底有多"官方"？

根据官方博客，这个扩展的核心是Kotlin by JetBrains。注意这个名字，不是社区维护的第三方插件，而是JetBrains亲儿子。

技术栈：

• 后端：Kotlin Language Server（基于IntelliJ IDEA的代码洞察基础设施）
• 前端：VS Code扩展（TypeScript）
• 通信：LSP协议

功能成熟度：

• ✅ 代码补全（智能感知）
• ✅ 错误诊断（编译时错误实时提示）
• ✅ 代码导航（跳转定义、查找引用）
• ✅ 快速修复（Quick Fixes）
• ✅ 代码格式化
• ✅ 项目导入（Gradle支持）
• ⚠️ 重构功能（Alpha版本暂不完整）
• ⚠️ 调试器（需要额外配置）

个人体验：我试用了Alpha版本，代码补全的准确度已经接近IDEA的80%，对于日常开发来说完全够用。但复杂的重构（比如安全重命名、提取接口）还是得回IDEA。

边界的消解与重构

写到这里，我突然想起以前读过的哲学家德勒兹的一个概念：“根茎”（Rhizome）

传统的工具生态像一棵树：有明确的根（核心产品）、干（主要功能）、枝（扩展功能）。但根茎不同，它没有中心，任何一点都可以连接到其他点，形成网状结构。

JetBrains的这个决定，恰恰体现了从"树状思维"到"根茎思维"的转变：

• 过去：IDEA是根，插件是枝，VS Code是敌人
• 现在：Kotlin是连接点，IDEA、VS Code、Fleet、其他LSP编辑器都是网络中的节点

这不是背叛，这是生态的进化。

“工具的界限，就是开发者世界的界限。”

当JetBrains主动打破IDEA的围墙，把Kotlin的智能带到VS Code时，它实际上在扩展Kotlin开发者的世界边界。

写在最后

回到文章开头的问题：该学IDEA还是VS Code？

我的答案是：都学，但理解它们的设计哲学。

• IDEA：深度优先，适合复杂项目、大型重构、企业级开发
• VS Code：广度优先，适合快速原型、多语言项目、轻量级编辑

而JetBrains为VS Code开发Kotlin插件这件事，教会我们一个更深层的道理：

真正的强者，不是守住自己的地盘，而是让自己的影响力无处不在。

Kotlin不需要你只用IDEA，它只需要你用Kotlin。

这，才是生态的胜利。

---