JetBrains 终于开源了 LSP 客户端！插件开发者必须知道的 5 个变化
不用再写自定义 LSP 客户端了！JetBrains 2026.2 开源背后的底层逻辑
你花了三周时间写了一个 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 这边的客户端代码。一旦开源，外部开发者大量涌入，这种命名混乱会把人逼疯。
所以新版命名直接对齐本质：
旧名称
新名称
含义LspServer``LspClient
IDE 端的 LSP 客户端LspServerSupportProvider``LspIntegrationProvider
负责集成和启动语言服务器的提供者
颗粒度很清晰：平台拥有客户端和 IDE 集成能力，语言服务器是外部进程。
如果你已经在用 JetBrains 的 LSP API，这两个改名是必跟的。建议现在就在代码里全局搜索 LspServer，提前做好迁移准备。
三、时间表提前：2026.1.4 就能用上，不用等到 2026.2
很多人看到 “2026.2” 的标题，以为要等到下半年。但 JetBrains 给出的时间表比预期更激进：
开源 LSP API 的工作已经规划进 2026.1.4 稳定版，不只是 2026.2 的 EAP。
这意味着：
- 你不用等几个月，下一个稳定版更新就能用上
- Android Studio 的支持可能来得更早——JetBrains 正在和 Google 团队对接推进
- 如果你现在就在开发插件，完全可以把最低版本要求往上提一提，提前适配新 API
建议：把 2026.1.4 设为你的里程碑版本，现在就开始在 EAP 里测试兼容性。
四、已有插件怎么办？迁移还是不迁移，看这一个决策树
这是大家最关心的问题。官方给出了非常务实的建议，我帮你整理成一个决策流程：
情况 1：你已经在用 JetBrains 的 LSP API
- • ✅ 必须迁移——API 改名是 breaking change
- • 关注 2026.1.4 和 2026.2 的更新日志
- • 把
LspServer替换为LspClient，把 provider 改为LspIntegrationProvider
情况 2：你在用 LSP4IJ 或自己写的自定义客户端
• ❌ 不要为了迁移而迁移
• 先问自己 5 个问题：
- 最低 IDE 版本要求是多少？新 API 是否覆盖？
- 是否需要 Android Studio 支持？（LSP4IJ 的支持情况如何？）
- 功能覆盖是否满足需求？（JetBrains 官方 client 的功能边界在哪里？）
- 是否需要深度定制？（官方 API 的 hooks 够不够？）
- 是否有远程开发或分屏模式需求？
如果以上 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 个变化，一张清单
序号
变化
你需要做什么
1
LSP Client API 全面开源
Android Studio 等平台即将支持，提前测试兼容性
2
API 重命名LspServer
→ LspClient，全局替换并适配
3
2026.1.4 提前落地
把最低版本要求提升到 2026.1.4，提前享受红利
4
迁移决策看场景
已在用官方 API 的必迁，用 LSP4IJ/自定义的不必强迁
5
新集成有标准路径
读官方文档 → 用模板生成 → 注册 Provider
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
本文转载自微信公众号，如有侵权请联系删除。
- 标题: JetBrains 终于开源了 LSP 客户端！插件开发者必须知道的 5 个变化
- 作者: lxiol
- 创建于 : 2026-06-30 15:35:49
- 更新于 : 2026-06-30 15:35:49
- 链接: https://blog.lxiol.cn/2026/06/30/JetBrains-终于开源了-LSP-客户端插件开发者必须知道的-5-个变化/
- 版权声明: 本文章采用 CC BY-NC-SA 4.0 进行许可。