Deno LSP 模块重构：文档与模块表示的分离

在 Deno 语言服务器协议(LSP)的实现中，当前存在一个重要的架构问题需要解决。本文将深入分析这个问题，探讨解决方案，并解释其技术意义。

当前架构的问题

目前 Deno 的 LSP 实现中，Document 结构体承载了过多职责，包含了从客户端文档状态到模块解析结果的各种信息。这种设计导致：

1. 内存占用过大，因为所有信息都被集中存储
2. 生命周期管理复杂，混合了短期和长期存在的数据
3. 难以实现某些功能优化，如静态资源的特殊处理

重构方案

新的设计将文档表示分为两个清晰的层次：

1. 基础文档表示

pub enum Document {
  Open(Arc<OpenDocument>),    // 客户端打开的文档
  Server(Arc<ServerDocument>) // 服务器管理的文档
}

这种区分反映了文档的不同来源和生命周期：

• OpenDocument 表示客户端正在编辑的文档，包含版本控制等编辑相关数据
• ServerDocument 表示服务器管理的资源，包括文件系统资源和内置静态资源

2. 模块相关信息的分离

模块解析、类型依赖等与语言特性相关的信息将被移到独立的"作用域特定存储"中。这种分离带来以下优势：

• 更精细的内存管理
• 更清晰的职责划分
• 更好的并发处理能力

技术实现细节

OpenDocument 结构

pub struct OpenDocument {
  uri: Uri,                   // 文档标识符
  text: Arc<str>,             // 文档内容
  line_index: Arc<LineIndex>, // 行索引(用于快速定位)
  version: i32,               // 版本控制
  language_id: LanguageId,    // 语言类型
}

ServerDocument 结构

pub struct ServerDocument {
  uri: Uri,                    // 资源标识符
  text: MaybeStaticSource,     // 可能是静态资源的特殊处理
  line_index: Arc<LineIndex>,  // 行索引
  kind: ServerDocumentKind,    // 资源类型分类
}

pub enum ServerDocumentKind {
  Fs { path: PathBuf, fs_version: String }, // 文件系统资源
  Const { specifier: Arc<Url> }              // 内置静态资源
}

重构的意义

1. 性能优化：通过分离静态资源处理，减少内存占用
2. 功能扩展：为测试模块等新功能提供更好的基础
3. 代码清晰度：更明确的职责划分使代码更易维护
4. 并发安全：减少共享状态，提高并发性能

对用户的影响

虽然这是内部架构调整，但最终用户将受益于：

• 更快的语言服务器响应速度
• 更低的内存占用
• 更稳定的功能表现
• 为未来功能(如更好的测试支持)奠定基础

这种重构体现了 Deno 团队对性能和质量的不懈追求，是 LSP 实现走向成熟的重要一步。