CRDT 与实时协作：从零理解无冲突复制数据类型的原理与实战

当 Figma 以 200 亿美元估值被 Adobe 收购时，很多人忽略了支撑其核心体验的技术——多人同时编辑同一份设计稿，光标实时可见，毫无延迟感。这背后不是传统的加锁机制，而是一种叫做 CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型） 的分布式数据结构。

2026 年，随着本地优先（Local-First）架构的兴起和 AI Agent 协作场景的爆发，CRDT 正在从学术概念变成每个开发者都需要理解的工程实践。Notion、Linear、Excalidraw、Tldraw 等明星产品都已全面拥抱 CRDT。如果你还在用轮询 + 版本号的方式处理数据同步，这篇文章会改变你的思路。

🧠 一、为什么 OT 不够用了？CRDT 的核心优势

OT（Operational Transformation）的困境

Google Docs 使用的 OT 算法在中心化架构下运行良好，但它有一个致命缺陷：必须依赖中心服务器来解决冲突。这意味着：

没有网络连接时无法离线编辑后同步
服务器成为性能瓶颈和单点故障
难以实现真正的端到端加密（P2P）

OT 的核心思路是「变换操作」——当两个用户同时编辑时，服务器将一个操作「变换」后再应用。这个过程复杂且容易出 bug，Google Docs 团队花了数年才让 OT 稳定运行。

CRDT 的解法：数学保证无冲突

CRDT 的核心思想完全不同：设计一种数据结构，使得无论操作以什么顺序执行，最终状态都一致。这不是工程上的 hack，而是数学上的保证。

⚡ 关键结论： CRDT 不需要中心服务器来解决冲突，这使得它天然支持离线优先、P2P 同步和去中心化架构。

CRDT vs OT 全面对比

对比维度	OT（Operational Transformation）	CRDT
冲突解决	依赖中心服务器	数学保证，无需中心
离线支持	❌ 非常困难	✅ 天然支持
P2P 同步	❌ 几乎不可能	✅ 原生支持
实现复杂度	高（边界 case 多）	中（数据结构复杂）
内存开销	低	较高（元数据开销）
典型应用	Google Docs	Figma, Notion, Yjs
文本编辑延迟	低	低（优化后）
端到端加密	❌	✅

💡 提示： CRDT 并不总是优于 OT。对于纯中心化、只需要服务端权威状态的场景，OT 实现更简单、内存更低。选择哪种方案取决于你的架构需求。

🔧 二、CRDT 核心类型与实现原理

CRDT 主要分为两大类：基于状态（State-based, CvRDT） 和 基于操作（Operation-based, CmRDT）。实际开发中最常用的三种数据结构是 G-Counter、LWW-Register 和 RGA。

2.1 G-Counter：分布式计数器

G-Counter 是最简单的 CRDT，解决的问题是：多个节点同时递增计数器，如何保证最终一致？

核心思路：每个节点维护自己的计数，合并时取各节点的最大值。

// g-counter.js — 分布式计数器 G-Counter 实现
class GCounter {
  constructor(nodeId) {
    this.nodeId = nodeId;
    this.counts = {}; // { nodeId: count }
  }

  // 递增本节点的计数
  increment() {
    if (!this.counts[this.nodeId]) {
      this.counts[this.nodeId] = 0;
    }
    this.counts[this.nodeId]++;
  }

  // 获取总值：所有节点计数之和
  value() {
    return Object.values(this.counts).reduce((sum, v) => sum + v, 0);
  }

  // 合并另一个 G-Counter：取各节点的最大值
  merge(other) {
    const allKeys = new Set([
      ...Object.keys(this.counts),
      ...Object.keys(other.counts)
    ]);
    for (const key of allKeys) {
      this.counts[key] = Math.max(
        this.counts[key] || 0,
        other.counts[key] || 0
      );
    }
  }
}

// 模拟两个节点同时递增
const nodeA = new GCounter('A');
const nodeB = new GCounter('B');

nodeA.increment(); // A: 1
nodeA.increment(); // A: 2
nodeB.increment(); // B: 1
nodeB.increment(); // B: 2
nodeB.increment(); // B: 3

// 合并：无论合并顺序如何，结果都是 5
nodeA.merge(nodeB);
nodeB.merge(nodeA);
console.log('Node A value:', nodeA.value()); // 5
console.log('Node B value:', nodeB.value()); // 5

2.2 LWW-Register：最后写入胜出寄存器

当多个节点同时修改同一个值时，用什么策略决定最终结果？LWW-Register（Last-Writer-Wins Register）的方案是：时间戳最大的写入胜出。

// lww-register.js — LWW-Register 实现，用于处理并发写入冲突
class LWWRegister {
  constructor() {
    this.value = null;
    this.timestamp = 0;
    this.nodeId = null; // 相同时间戳时用 nodeId 作为 tiebreaker
  }

  // 设置值，需要传入时间戳
  set(value, timestamp, nodeId) {
    // 只有时间戳更大，或者时间戳相同但 nodeId 更大时才更新
    if (
      timestamp > this.timestamp ||
      (timestamp === this.timestamp && nodeId > this.nodeId)
    ) {
      this.value = value;
      this.timestamp = timestamp;
      this.nodeId = nodeId;
    }
  }

  // 合并另一个 LWW-Register
  merge(other) {
    if (
      other.timestamp > this.timestamp ||
      (other.timestamp === this.timestamp && other.nodeId > this.nodeId)
    ) {
      this.value = other.value;
      this.timestamp = other.timestamp;
      this.nodeId = other.nodeId;
    }
  }
}

// 模拟两个节点同时修改用户名
const regA = new LWWRegister();
const regB = new LWWRegister();

// 节点 A 在 T=100 修改为 "alice"
regA.set('alice', 100, 'node-A');
// 节点 B 在 T=101 修改为 "bob"（时间戳更大，胜出）
regB.set('bob', 101, 'node-B');

// 合并后，无论先合并谁，结果都是 "bob"
regA.merge(regB);
console.log('最终值:', regA.value); // "bob"

⚠️ 警告： LWW-Register 依赖物理时钟或逻辑时钟的准确性。在分布式系统中，时钟漂移是常见问题。实际项目中建议使用混合逻辑时钟（Hybrid Logical Clock, HLC）来保证因果序。

2.3 RGA：Replicated Growable Array（文本编辑核心）

文本协作编辑是 CRDT 最经典的应用场景。RGA 是大多数文本 CRDT 的基础，它维护一个有序数组，支持任意位置的插入和删除，同时保证多节点并发操作后的一致性。

核心思路：每个字符元素都有一个唯一 ID（通常是 节点ID + 逻辑时间戳），插入操作通过「锚定到前一个元素」来确定位置。

// rga-simplified.js — RGA 简化实现，展示文本协作编辑的核心原理
class RGANode {
  constructor(id, char, deleted = false) {
    this.id = id;       // 唯一标识：{ nodeId, timestamp }
    this.char = char;   // 字符内容
    this.deleted = deleted; // 是否被删除（tombstone）
    this.next = null;
  }
}

class RGADocument {
  constructor(nodeId) {
    this.nodeId = nodeId;
    this.head = new RGANode({ nodeId: 'root', timestamp: 0 }, '');
    this.clock = 0;
    this.nodeMap = new Map(); // id key -> node，用于快速查找
    this.nodeMap.set('root', this.head);
  }

  // 获取唯一 ID
  nextId() {
    this.clock++;
    return { nodeId: this.nodeId, timestamp: this.clock };
  }

  // 在指定节点后插入字符
  insertAfter(anchorId, char) {
    const anchor = this.nodeMap.get(anchorId);
    if (!anchor) throw new Error(`Anchor node ${anchorId} not found`);

    const id = this.nextId();
    const newNode = new RGANode(id, char);

    // 插入到 anchor 之后
    newNode.next = anchor.next;
    anchor.next = newNode;
    this.nodeMap.set(id, newNode);
    return id;
  }

  // 删除指定节点（标记为 tombstone）
  delete(nodeId) {
    const node = this.nodeMap.get(nodeId);
    if (node) node.deleted = true;
  }

  // 合并另一个 RGA 文档
  merge(other) {
    // 遍历 other 的所有节点，按顺序插入
    let current = other.head;
    while (current) {
      if (!this.nodeMap.has(current.id)) {
        // 找到锚点（前驱节点在本地文档中的对应节点）
        const anchor = this.nodeMap.get(current.prevId);
        if (anchor) {
          const newNode = new RGANode(current.id, current.char, current.deleted);
          newNode.next = anchor.next;
          anchor.next = newNode;
          this.nodeMap.set(current.id, newNode);
        }
      }
      current = current.next;
    }
  }

  // 渲染文档内容（跳过已删除的节点）
  toString() {
    const chars = [];
    let current = this.head.next;
    while (current) {
      if (!current.deleted) chars.push(current.char);
      current = current.next;
    }
    return chars.join('');
  }
}

// 使用示例
const docA = new RGADocument('A');
const rootId = 'root';
const h = docA.insertAfter(rootId, 'H');
const e = docA.insertAfter(h, 'e');
const l1 = docA.insertAfter(e, 'l');
const l2 = docA.insertAfter(l1, 'l');
const o = docA.insertAfter(l2, 'o');
console.log('Node A:', docA.toString()); // "Hello"

// 节点 B 从同一份文档开始，独立修改
const docB = new RGADocument('B');
// B 也构建了 "Hello"，然后在 "He" 后面插入 "y"
// （实际实现中 B 的初始状态是通过同步获得的）

console.log('RGA 实现文本协作编辑的核心原理已展示');

📌 记住： 实际的 RGA 实现（如 Yjs 的 Y.Text）比上述简化版复杂得多，需要处理远程操作的因果序、并发插入的排序策略、tombstone 压缩等问题。但核心原理——唯一 ID + 锚定插入 + tombstone 标记——是不变的。

🚀 三、生产级 CRDT 库实战：Yjs vs Automerge

3.1 Yjs：高性能的选择

Yjs 是目前最成熟的 CRDT 库，被 Notion、Tldraw、Hocuspocus 等项目采用。它的核心优势是 极高的性能和极低的内存开销。

# 安装 Yjs 及其 WebSocket Provider
npm install yjs y-websocket

// yjs-collab-demo.js — 使用 Yjs 实现多人实时协作编辑
import * as Y from 'yjs';
import { WebsocketProvider } from 'y-websocket';

// 1. 创建 Yjs 文档
const ydoc = new Y.Doc();

// 2. 定义共享数据结构
const ytext = ydoc.getText('editor');       // 共享文本
const ymap = ydoc.getMap('metadata');       // 共享键值对
const yarray = ydoc.getArray('comments');  // 共享数组

// 3. 连接到 WebSocket 服务器（多人同步）
const provider = new WebsocketProvider(
  'wss://your-server.com',  // WebSocket 服务器地址
  'document-room-123',       // 房间 ID
  ydoc
);

// 4. 监听连接状态
provider.on('status', event => {
  console.log('连接状态:', event.status); // "connected" | "disconnected"
});

// 5. 监听远端更新
ytext.observe(event => {
  console.log('文本变更:', ytext.toString());
  // 更新编辑器 UI（CodeMirror、Monaco 等）
});

// 6. 本地修改（自动同步到所有客户端）
ytext.insert(0, 'Hello, CRDT!');
ymap.set('title', '协作文档标题');
ymap.set('lastEditor', 'user-123');
yarray.push([{ user: 'alice', text: '这是一条评论', time: Date.now() }]);

// 7. 获取文档二进制编码（用于持久化或 P2P 传输）
const stateVector = Y.encodeStateVector(ydoc);
const update = Y.encodeStateAsUpdate(ydoc);
// 可以存储到 IndexedDB、发送到其他 peer 等

// 8. 离线编辑 + 重新连接后自动同步
// Yjs 会自动合并离线期间的所有修改，无需手动处理冲突

3.2 Automerge：更接近原生 JS 体验

Automerge 由 Ink & Switch 实验室开发，设计哲学是「像操作普通 JS 对象一样操作 CRDT」。

// automerge-demo.js — 使用 Automerge 实现本地优先数据同步
import * as Automerge from '@automerge/automerge';

// 1. 创建文档
let doc = Automerge.init();

// 2. 像修改普通对象一样修改（Automerge 内部追踪所有变更）
doc = Automerge.change(doc, '创建任务列表', d => {
  d.todos = [
    { text: '学习 CRDT', done: false },
    { text: '实现协作编辑', done: false },
  ];
});

// 3. 模拟两个客户端并发修改
let docA = Automerge.clone(doc);
let docB = Automerge.clone(doc);

// 用户 A 标记第一个任务完成
docA = Automerge.change(docA, '完成第一个任务', d => {
  d.todos[0].done = true;
});

// 用户 B 同时添加新任务
docB = Automerge.change(docB, '添加新任务', d => {
  d.todos.push({ text: '写单元测试', done: false });
});

// 4. 合并两个文档（自动解决冲突）
let merged = Automerge.merge(docA, docB);
console.log('合并结果:', JSON.stringify(merged.todos, null, 2));
// 两个用户的修改都被保留：任务 1 标记完成 + 新任务被添加

// 5. 获取同步增量（用于网络传输）
const changesA = Automerge.getChanges(Automerge.init(), docA);
const changesB = Automerge.getChanges(Automerge.init(), docB);
// 可以通过任何传输方式发送 changes（HTTP、WebSocket、蓝牙等）

// 6. 查看变更历史
const history = Automerge.getHistory(merged);
history.forEach(state => {
  console.log(`版本 ${state.change.message}:`, state.snapshot.todos);
});

3.3 性能实测对比

选择正确的 CRDT 库对性能影响巨大。以下是基于标准 benchmark 的对比数据：

测试场景	Yjs	Automerge 2.0	差距
10 万次随机插入	85ms	320ms	Yjs 快 3.8x
文档大小（10 万操作后）	1.2 MB	4.8 MB	Yjs 小 4x
合并 2 个文档（各 5 万操作）	12ms	58ms	Yjs 快 4.8x
内存占用（实时编辑中）	15 MB	42 MB	Yjs 小 2.8x
初始加载时间	20ms	95ms	Yjs 快 4.7x

⚡ 关键结论： 如果你的场景是实时文本协作或需要处理大量操作，Yjs 是性能最优选。如果你更看重 API 易用性和类型安全（TypeScript），Automerge 的开发体验更好。

💡 四、避坑指南与最佳实践

4.1 常见坑点

坑点 1：Tombstone 导致内存爆炸

CRDT 的删除操作通常使用 tombstone（墓碑标记），即不真正删除元素，只标记为已删除。在长期运行的文档中，tombstone 会持续累积。

// ❌ 错误：长期运行的文档没有清理 tombstone
// 一个编辑了 1 年的文档，即使只剩 1000 字符，
// tombstone 可能占用 50MB+ 内存

// ✅ 正确：定期执行 garbage collection
// Yjs 的方案：确保所有客户端都同步到最新状态后，才能安全清理 tombstone
// 使用 Y.encodeStateVector() 检查各客户端状态
const stateVector = Y.encodeStateVector(ydoc);
// 只有当所有客户端的 stateVector 都超过某个阈值时，才能安全清理

坑点 2：因果序混乱导致状态不一致

在网络分区恢复后，如果操作没有按因果序应用，可能导致中间状态出现「不可能」的数据。

// ⚠️ 注意：不要手动绕过 CRDT 库的合并逻辑
// ❌ 错误：直接操作底层数据
doc.todos[0] = { text: '被覆盖了', done: true };

// ✅ 正确：通过 CRDT API 操作
doc = Automerge.change(doc, '更新任务', d => {
  d.todos[0].text = '正确修改';
  d.todos[0].done = true;
});

坑点 3：过度使用 CRDT 导致架构复杂

不是所有数据都需要 CRDT。用户偏好设置、静态配置、低频更新的数据用传统同步方案即可。

// ❌ 避免：为所有数据都创建 CRDT 共享结构
const yPrefs = ydoc.getMap('preferences');   // 不需要 CRDT
const yTheme = ydoc.getMap('theme');          // 不需要 CRDT
const yContent = ydoc.getText('document');    // ✅ 需要 CRDT
const yComments = ydoc.getArray('comments'); // ✅ 需要 CRDT

4.2 生产环境最佳实践

✅ 使用 IndexedDB 持久化：Yjs 配合 y-indexeddb 实现离线数据保存，避免页面刷新丢失数据
✅ 设置 Awareness 协议：实时显示协作者光标位置、在线状态，提升用户体验
✅ 实施权限控制：CRDT 本身不处理权限，需要在应用层实现读写权限
✅ 监控 tombstone 增长：设置告警阈值，当 tombstone 占比超过 70% 时触发压缩
✅ 使用二进制编码传输：Y.encodeStateAsUpdate() 的二进制格式比 JSON 小 5-10 倍
❌ 避免在 CRDT 中存储大文件：大文件应存储在对象存储（如 S3），CRDT 中只存引用

🎯 总结

CRDT 不是银弹，但它解决了分布式协作中最棘手的问题——如何在没有中心协调者的情况下保证数据最终一致。对于实时协作编辑、离线优先应用、P2P 数据同步等场景，CRDT 是目前最优雅的工程方案。

技术选型建议：

🔥 需要极致性能 → 选 Yjs，它是目前最快的 CRDT 实现
📐 需要复杂嵌套数据结构 → 选 Automerge，它的 API 更自然
🏢 需要中心化 + 协作 → OT（如 ShareDB）可能更简单
🌐 需要去中心化 / P2P → CRDT 是唯一选择