语言能力放在扩展宿主还是拆成语言服务器？

结论

能力少、逻辑轻、只服务 VS Code 时，可以直接在扩展宿主里注册 Provider。语言规则复杂、要复用给别的编辑器、计算会卡住界面，或者要用独立运行时时，拆成语言服务器。

展开

放在扩展宿主：

• 启动快，少一个进程
• 直接用 vscode API，少一层协议转换
• 适合片段补全、简单悬停、工作区扫描一类轻功能
• 缺点是和 VS Code 绑死，耗时计算堵的是扩展宿主，所有插件一起受影响

拆成语言服务器：

• 语言逻辑跑在独立进程，崩溃可以重启，不拖垮界面
• 走语言服务器协议，同一套服务能接 Vim、其他编辑器
• 适合补全、诊断、重构、类型检查这种完整语言
• 代价是要维护客户端和服务器、文本同步、取消和日志

面试时的判断句可以是：如果这份逻辑离开 VS Code 仍然成立，它就该住在服务器里；如果强依赖树视图、Webview 或 VS Code 专有界面，留在扩展里。

常见拆法是扩展负责激活、配置、日志和界面，服务器负责文本和语言。不要两边都算一遍诊断。

容易讲错的点

• 上了语言服务器不等于扩展里不能再注册任何 Provider。和语言无关的命令、视图仍然留在扩展里。
• 服务器无状态假设是错的。服务器要维护已打开文档的副本，扩展宿主那边的未保存内容靠同步协议送过去。
• 「先写在扩展里，以后再抽」可以，但诊断坐标、取消和增量更新一开始就要有，不然迁移时交互会整个重写。