JetBrains 终于开源了 LSP 客户端！插件开发者必须知道的 5 个变化

你花了三周时间写了一个 IntelliJ 插件，集成了某个语言服务器，本地测试完美通过。结果用户反馈说："Android Studio 上完全没反应。"

你排查了半天，发现不是代码 bug，而是 LSP 集成本身在 Android Studio 里根本跑不起来。因为 JetBrains 的 LSP 客户端一直是商业 IDE 的专属功能，开源的 IntelliJ Platform 并不包含它。

没有报错提示，没有降级方案，用户只能干瞪眼。

这种情况，从 2026.2 开始，终于要终结了。JetBrains 正式宣布将 LSP Client API 全面开源。今天这篇文章，给你梳理 5 个必须知道的变化，看完你就知道该怎么行动。

一、LSP Client API 开源：从商业封闭到全平台可用

LSP（Language Server Protocol）的底层逻辑很简单：把语言支持从 IDE 里抽出来，交给一个独立的语言服务器，IDE 只负责当"客户端"。一套服务器，N 个编辑器都能用。

但问题是，协议只是协议。谁来启动服务器、怎么处理代码、怎么和编辑器深度集成——这些脏活累活，IDE 厂商还是得自己干。

以前，JetBrains 把这套客户端能力放在了商业 IDE 扩展里。你的插件在 IntelliJ IDEA 里能跑，到了 Android Studio（基于开源平台构建）就哑火。

一个真实的案例：Azure DevOps Pipeline 插件的作者，明明在插件里正确注册了 platform.lsp.serverSupportProvider，打开 azure-pipelines.yml 文件时语言服务器就是启动不了。原因无他，Android Studio 没有这个商业扩展。

另一个更极端的例子：Noctule（Swift 插件）的作者干脆从零写了一个自定义 LSP 客户端。不是因为想炫技，而是因为现有的选项要么不支持 Android Studio，要么版本兼容性不可控，要么集成深度不够。

2026.2 之后，这些痛点被一次性拉通。

JetBrains 把稳定、久经沙场的 LSP 客户端开源到 IntelliJ Platform，意味着：

• • Android Studio 能用
• • 其他基于开源平台的产品也能用
• • 插件开发者再也不用为"这个平台支不支持"头疼

金句：协议是通用的，但客户端能力才是护城河。JetBrains 这次把护城河变成了基础设施。

二、API 大改名：LspServer → LspClient，命名终于对齐了

开源不只是"把代码放出来"，JetBrains 还顺手做了一次顶层设计——API 重命名。

旧的命名有个致命问题：LspServer 听起来像是"语言服务器"，但实际上它代表的是 IDE 这边的客户端代码。一旦开源，外部开发者大量涌入，这种命名混乱会把人逼疯。

所以新版命名直接对齐本质：

颗粒度很清晰：平台拥有客户端和 IDE 集成能力，语言服务器是外部进程。

如果你已经在用 JetBrains 的 LSP API，这两个改名是必跟的。建议现在就在代码里全局搜索 LspServer，提前做好迁移准备。

三、时间表提前：2026.1.4 就能用上，不用等到 2026.2

很多人看到 "2026.2" 的标题，以为要等到下半年。但 JetBrains 给出的时间表比预期更激进：

开源 LSP API 的工作已经规划进 2026.1.4 稳定版，不只是 2026.2 的 EAP。

这意味着：

1. 1. 你不用等几个月，下一个稳定版更新就能用上
2. 2. Android Studio 的支持可能来得更早——JetBrains 正在和 Google 团队对接推进
3. 3. 如果你现在就在开发插件，完全可以把最低版本要求往上提一提，提前适配新 API

建议：把 2026.1.4 设为你的里程碑版本，现在就开始在 EAP 里测试兼容性。

四、已有插件怎么办？迁移还是不迁移，看这一个决策树

这是大家最关心的问题。官方给出了非常务实的建议，我帮你整理成一个决策流程：

情况 1：你已经在用 JetBrains 的 LSP API

• • ✅ 必须迁移——API 改名是 breaking change
• • 关注 2026.1.4 和 2026.2 的更新日志
• • 把 LspServer 替换为 LspClient，把 provider 改为 LspIntegrationProvider

情况 2：你在用 LSP4IJ 或自己写的自定义客户端

• • ❌ 不要为了迁移而迁移
• • 先问自己 5 个问题：
  1. 1. 最低 IDE 版本要求是多少？新 API 是否覆盖？
  2. 2. 是否需要 Android Studio 支持？（LSP4IJ 的支持情况如何？）
  3. 3. 功能覆盖是否满足需求？（JetBrains 官方 client 的功能边界在哪里？）
  4. 4. 是否需要深度定制？（官方 API 的 hooks 够不够？）
  5. 5. 是否有远程开发或分屏模式需求？

如果以上 5 个问题里，官方 API 能覆盖 80% 以上，再考虑迁移。否则，维护现有方案可能更省成本。

金句：技术选型没有银弹，只有场景匹配。

五、新语言集成怎么开始？官方给出了两条路

如果你要为一个新语言做 IntelliJ 插件集成，而且该语言已经有成熟的服务器实现，官方推荐的路径很清晰：

路径 A：已有语言服务器

• • 先去读 IntelliJ Platform SDK Docs 里的 LSP 专题文章[1]
• • 了解平台提供的 client 能力边界
• • 注册 LspIntegrationProvider，实现启动逻辑

路径 B：从零搭建插件

• • 用 IntelliJ Platform Plugin Template[2] 一键生成项目骨架
• • 或者在 IntelliJ IDEA 里安装 Plugin DevKit 插件，用新版 Project Wizard 创建

两条路的共同前提：先确认你的语言服务器本身稳定可用。IDE 集成只是最后一公里，服务器质量决定了用户体验天花板。

总结：5 个变化，一张清单

JetBrains 这次开源 LSP Client API，表面上是"放代码"，本质上是在拉通整个插件生态的底层基础设施。对于插件开发者来说，这意味着更少的平台差异、更统一的行为预期、更低的维护成本。

今天可以先做的第一步： 打开你的插件代码，搜索 LspServer，看看哪些地方需要改名。这个动作不超过 5 分钟，但能让你在新版本发布时从容不迫。

你有插件正在用 LSP 吗？遇到的最大痛点是什么？欢迎在评论区聊聊，大家一起对齐颗粒度。

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

支持我们，点赞或分享到朋友圈！

引用链接

[1] IntelliJ Platform SDK Docs 里的 LSP 专题文章: https://plugins.jetbrains.com/docs/intellij/language-server-protocol.html [2] IntelliJ Platform Plugin Template: https://github.com/JetBrains/intellij-platform-plugin-template