实时协同编辑是现代协作工具的核心能力，从 Google Docs 到 Figma，再到各种在线代码编辑器，多人同时编辑同一文档的需求愈发普遍。CodeMirror 作为业界领先的 Web 代码编辑器，其第六版在协同编辑支持上提供了两套成熟方案：基于操作转换（Operational Transformation，OT）的中心化架构，以及基于 CRDT（Conflict-free Replicated Data Type）的去中心化方案。本文从工程实践角度，系统梳理两套方案的核心原理、关键参数与落地要点，帮助开发者在项目中快速搭建可靠的实时协作能力。
中心化 OT 方案：@codemirror/collab 的工程实现
CodeMirror 6 内置的协同编辑能力基于 OT 算法实现，依赖 @codemirror/collab 包提供核心工具函数。这套方案采用经典的主从架构：存在一个中心权威节点（Authority）维护完整的变更历史，所有客户端（Peer）围绕该权威节点进行同步。
权威节点的设计要点
权威节点的核心职责是三件事：存储变更历史、维护当前文档状态、以及为新加入的客户端提供起始状态。在 CodeMirror 的官方示例中，权威节点可以用一个 Web Worker 甚至是服务端进程来实现，其状态仅包含两个字段：已接收的更新数组（包含 ChangeSet 和客户端标识）以及当前文档内容。权威节点需要处理三种消息类型：pullUpdates 用于客户端拉取自某版本以来的所有更新，pushUpdates 用于客户端提交本地变更，getDocument 用于新客户端获取初始文档和版本号。
关键工程参数在于版本号的精确管理。客户端每次推送更新时必须携带当前已同步的版本号，如果版本号与权威节点当前版本不匹配，权威节点可以选择拒绝更新（简单但可能导致客户端饥饿）或执行 rebase 操作后接受。CodeMirror 6 提供了 rebaseUpdates 函数来处理这种版本冲突，通过将客户端的更新与权威节点的新变更进行变换重组，确保最终所有客户端能看到一致的文档状态。在网络延迟较高或多人频繁编辑的场景下，建议启用 rebase 策略而非直接拒绝，以避免低延迟客户端长期无法提交更新的饥饿问题。
客户端插件的实现模式
客户端通过 ViewPlugin 实现与权威节点的通信。该插件在内部维护一个异步循环，持续从权威节点拉取最新更新并通过 receiveUpdates 函数应用到本地编辑器状态。当用户在编辑器中触发变更时，插件将本地变更打包为 Update 对象并推送给权威节点。CodeMirror 提供了 sendableUpdates 和 getSyncedVersion 两个辅助函数，分别用于获取待提交的变更和当前已同步的版本号。
实现时需要特别注意推拉流程的调度策略。简单的实现可能同时发起推送和拉取请求，但在高并发场景下这可能导致状态不一致。更好的做法是将推送和拉取纳入统一的状态机管理，确保任意时刻只执行其中一种操作。此外，推送失败或网络中断时应有重试机制 —— 官方示例中使用了简单的 setTimeout 延迟重试，生产环境建议配合指数退避算法和最大重试次数限制。
旧版本数据的压缩与清理
默认实现会无限积累所有历史变更，这在长期使用的文档上会导致内存和带宽开销持续增长。可选的优化策略包括定期压缩历史记录和使用 ChangeSet.compose 将多个细粒度变更合并为粗粒度版本。但这种压缩是有代价的：自压缩点之后离线的客户端将无法再同步到最新状态，因为它们所需的中间变更已不存在。工程决策取决于具体场景 —— 对于协作周期较短且客户端稳定性较高的场景，定期压缩是值得的；对于需要支持长时间离线后恢复的场景，则应保留更完整的历史甚至考虑引入 CRDT 方案。
Yjs CRDT 方案：离线优先的协同编辑
OT 方案依赖于中心权威节点，这意味着所有流量必须经过服务器，且服务器宕机将导致协作中断。对于需要更强容错能力或希望实现点对点直接协作的场景，Yjs 生态提供的 CRDT 方案是更优选择。Yjs 是一种无冲突复制数据类型，专门为分布式协同编辑设计，能够在不需要中心协调者的情况下实现最终一致性。
y-codemirror.next 绑定
CodeMirror 6 与 Yjs 的集成通过 y-codemirror.next 包实现。该绑定将 Yjs 的 Y.Text 类型与 CodeMirror 的 EditorState 进行双向同步：本地编辑会被转换为 Yjs 更新并传播到其他客户端，远程 Yjs 更新则被应用到本地编辑器。绑定还负责同步光标位置和选区信息，使得用户可以看到协作者的光标位置。
CRDT 方案的核心优势在于离线支持。由于每个客户端都维护完整的数据副本，网络中断期间用户可以继续编辑，恢复连接后各客户端的状态会自动合并且不会产生冲突。这对于移动网络场景或需要高度容错的应用尤为重要。此外，Yjs 生态提供了丰富的后端适配器，包括 WebSocket、WebRTC、IndexedDB 持久化等，开发者可以根据需求灵活选择传输层。
位置映射的特殊考量
OT 和 CRDT 方案在位置映射上存在本质差异。OT 中，中心权威节点负责为所有操作赋予全局顺序，位置映射相对简单。但在 CRDT 方案中，由于各客户端可能以不同顺序应用变更，位置映射无法保证全局一致性。Yjs 通过相对位置（Relative Position）机制来处理这一问题，它不依赖绝对字符位置而是依赖文档结构关系。尽管如此，在某些复杂场景下（如同时编辑且变更高度重叠），不同客户端上同一相对位置可能映射到不同的绝对坐标。开发者在实现高亮、锚点等功能时需要意识到这一限制，必要时可引入额外的同步机制。
工程落地的关键参数清单
基于上述分析，将 CodeMirror 6 协同编辑方案落地生产环境时，以下参数和配置值得重点关注。
在 OT 方案中，推送重试间隔建议设置为 100 毫秒至 500 毫秒之间，首次失败后采用指数退避策略，最大重试次数建议限制在 5 至 10 次以防止无限重试。对于历史压缩策略，压缩间隔可根据文档大小和协作频率调整，通常建议每 1000 次变更或每 24 小时执行一次压缩，压缩时保留最近 5000 次完整变更以支持短期离线恢复。网络超时设置应考虑移动端网络波动，建议推送超时设置为 10 秒、拉取超时设置为 30 秒。
在 CRDT 方案中，Yjs 的 update 消息批量大小建议控制在 10KB 至 50KB 范围内以平衡延迟和吞吐量。WebSocket 连接的心跳间隔建议设置为 30 秒以尽早检测连接断开。IndexedDB 持久化应在每次本地变更后触发，但批量写入间隔建议不低于 100 毫秒以避免频繁写入影响性能。对于光标同步，Yjs 提供了 Awareness 协议，建议将本地用户信息（名称、颜色等）通过该协议传播，远程光标更新频率建议控制在每秒 10 次以内以减少网络开销。
方案选型建议
选择 OT 还是 CRDT 方案需要权衡多个因素。如果协作场景需要强一致性和完整的审计日志，且可以接受中心化架构的局限性，OT 方案实现更成熟、调试更简单；如果需要离线编辑能力、点对点协作或更高的容错性，CRDT 方案是更合适的选择。许多现代协作产品（如 FFmpeg Wiki、Hacker News 编辑器等）已采用 Yjs 方案，验证了其工程可行性。
对于大多数 Web 端代码编辑器协作场景，建议从 OT 方案起步，其与 CodeMirror 6 的集成更紧密，文档和社区支持更完善。在产品演进产生离线协作或去中心化需求时，再平滑迁移到 Yjs 方案。两套方案在 API 层面具有相似性，迁移成本可控。
资料来源：CodeMirror 官方协作编辑示例（https://codemirror.net/examples/collab/）