LSP 在 Theia 中的客户端架构：前端、后端与语言服务管理

这一篇从 Theia 的角度看 LSP：前端有哪些 LSP 相关组件，后端如何管理语言服务器进程，两端之间的数据是怎么流动的。

在 Theia 里，和 LSP 相关的大致可以分成三层：

  • 前端：

    • Monaco 编辑器与文档模型；
    • LSP 客户端与各语言前端适配层；
    • Markers、代码操作、命令等 UI 层集成。

  • 后端：

    • 语言服务器进程管理（启动/停止 LS）；
    • 与实际 Language Server 之间的 JSON-RPC 通信。

  • 协议层：

    • LSP 消息的编解码与转发；
    • 文档同步、请求/响应、通知在前后端之间的桥接。

可以理解为：
前端负责“把 IDE 的行为翻译成 LSP 消息，并把结果渲染出来”，后端负责“让语言服务器活着并收发消息”。

前端侧通常包含以下几类组件：

  • 文档/编辑器服务：

    • 管理 Monaco 模型与编辑器 Widget；
    • 对文档的打开、关闭、保存等操作进行统一处理。

  • LSP 客户端：

    • 对某种语言或一组语言负责与对应 Language Server 的通信；
    • 将文档事件和用户请求（补全、hover、definition 等）打包成 LSP 消息发送给后端。

  • 结果适配层：

    • 接收 LSP 响应和通知；
    • 更新 Markers、提供补全项、hover 内容等；
    • 调用 Monaco 的相关 API（装饰器、语言提供者）更新 UI。

这部分通过依赖注入（InversifyJS）挂到容器里，
其它扩展可以通过注入这些服务，在不知道 LSP 细节的情况下获得语言能力。

后端负责与实际语言服务器进程打交道，这通常包括：

  • 语言服务器进程的启动/停止：

    • 按语言配置（Executable/Command/Node module 等）启动进程；
    • 监控进程状态，必要时重启或清理。

  • 连接与路由：

    • 为每个 Language Server 建立一个 JSON-RPC 连接（stdio/TCP/WebSocket）；
    • 为前端来的请求/通知选择正确的 Language Server 并转发；
    • 把 Language Server 的响应/通知转回前端对应的 LSP 客户端。

  • 工作区与文件系统集成：

    • 将工作区根、文件更改等信息通过 LSP 的 workspace 相关请求/通知传递给 Language Server。

在这种结构下，前端不需要关心 Language Server 具体是用什么语言实现、跑在哪个进程或容器里，
只需要通过约定好的通道发送 LSP 消息即可。

前后端之间有一条专门的 LSP 通道，用来承载 JSON-RPC 消息。
桥接组件负责：

  • 将前端 LSP 客户端发出的请求/通知包装后发送到后端；
  • 将后端 Language Server 发回的消息解包并分发给正确的前端客户端；
  • 在多工作区、多语言、多文档的场景下，根据文档 URI、语言 ID 等信息做路由。

一个常见的分工是：

  • 文档事件（didOpen/didChange/didClose）由前端文档服务触发；
  • LSP 客户端监听这些事件并构造协议消息；
  • 通过消息通道发送到后端指定的 Language Server；
  • 后端只关心消息的协议正确性和哪一个语言服务器实例应该处理。

实际项目通常不会只有一个 Language Server，
Theia 需要处理多语言、多 Language Server 并存的情况：

  • 为每种语言配置对应的 Language Server（有时一个 LS 支持多种语言）；
  • 根据文档的语言 ID 或扩展名选择合适的 LSP 客户端与后端服务器；
  • 管理多个 Language Server 的生命周期与资源占用。

在前端，这意味着：

  • 一个文档的语言 ID 会决定它被哪一个 LSP 客户端接管；
  • 若文档语言切换（例如配置变化）需要重新建立对应的 LSP 绑定。

在后端，这意味着：

  • 需要一套注册表来管理“语言 → Language Server 配置”的映射；
  • 需要为不同 LS 实例维护各自的连接与进程信息。

Theia 使用 InversifyJS 管理 LSP 相关服务与扩展点：

  • LSP 客户端、文档服务、Markers 服务等都作为可注入服务绑定在容器里；
  • 语言相关扩展可以通过绑定自己的 LanguageClientContribution 来声明“如何连接到某个 Language Server”；
  • 其它扩展只需依赖抽象接口（如文档服务、诊断服务），不需要了解具体 LSP 客户端的细节。

这种结构让：

  • 单独开发的语言扩展可以独立演进和测试；
  • IDE 主体只负责提供通用的 LSP 基础设施和 UI 承载；
  • 当增加新语言支持时，只需增加新扩展并配置好对应的 Language Server。

在 Theia 中，LSP 客户端架构大致可以归纳为：

  • 前端：负责把编辑器行为翻译为 LSP 消息，并把服务器结果映射到 Monaco 和 Theia 的 UI 上；
  • 后端：负责运行语言服务器进程，并为它们提供稳定的 JSON-RPC 通道；
  • 依赖注入层：把这些组件模块化，并通过扩展点开放给各语言插件使用。

理解这三层的分工，有助于在看 Theia LSP 相关源码时快速定位：
某个问题是出在“前端适配”、还是“消息桥接”、还是“语言服务器本身”。**