vs
抱歉，刚才理解错了。你指的OT、CRDT、Yjs都是实时协同编辑领域的核心技术，用于解决多人同时修改同一份数据时的冲突问题。
下面逐一说明：
1. OT（Operational Transformation，操作转换）
- 本质：将用户的每次编辑封装成操作（insert/delete/retain），当多个操作并发时，通过转换函数动态调整操作参数，使得所有客户端最终收敛到一致状态。
- 代表项目：Google Docs（早期版本）、Etherpad、Firepad。
- 优点：成熟、工业应用广泛、文本编辑场景表现稳定。
- 缺点：转换函数复杂（尤其对复杂数据类型），需要中心服务器或全序广播，实现正确性极难。
2. CRDT（Conflict-free Replicated Data Type，无冲突复制数据类型）
- 本质：设计一种数据结构，其状态或操作天然具有交换律、结合律、幂等性（合并时无需转换）。分为两类：
- 状态 CRDT（CvRDT）：仅同步完整状态，合并时自动无冲突。
- 操作 CRDT（CmRDT）：只同步操作，要求操作可交换（基于因果顺序）。
- 代表项目：Redis CRDT、Miro、Figma（部分使用）。
- 优点：数学上保证无冲突，无需中心转换逻辑，分布式友好。
- 缺点：内存开销大（需要保存元数据如版本向量），某些操作性能不如 OT。
3. Yjs
- 本质：一个基于 CRDT 的高性能实时协同框架，并非全新算法，而是对 CRDT 理念的高效工程实现。
- 特点：
- 支持文本、数组、Map、XML 等丰富数据类型。
- 使用结构共享（类似不可变数据）和删除墓碑标记，避免大对象复制。
- 提供网络绑定（WebRTC、WebSocket、IndexedDB 持久化）。
- 代表作：VS Code Live Share 早期实验、AFFiNE、许多协同白板/文档工具。
- 优点：易用、性能优异、社区活跃，支持离线编辑后自动合并。
- 缺点：极端大规模文档（几万次操作）下 GC 压力增大。
三者的核心区别
| 特性 | OT | CRDT | Yjs |
|---|---|---|---|
| 冲突解决方式 | 操作转换函数 | 数据代数性质保证 | CRDT + 优化数据结构 |
| 实现难度 | 高（转换函数易错） | 中（数据结构设计难度大） | 低（使用现成库） |
| 中心服务器 | 通常需要（或总序广播） | 可选（去中心化） | 可选（支持 P2P） |
| 内存/性能 | 较好 | 较差（元数据多） | 优化后接近 OT |
| 典型应用 | Google Docs（旧）、Etherpad | Figma、Redis CRDT | Yjs、AFFiNE、思源笔记 |
当前趋势
- Yjs 逐渐成为首选（替代 ShareDB 等 OT 方案），因为它结合了 CRDT 的数学正确性和工程优化。
- 现代协同应用（如 Logseq、Anytype）多基于 CRDT/Yjs。
- Google Docs 已放弃纯 OT，转而使用自己的 Fluid Framework（混合了 OT 和 CRDT 思想）。
如果你需要，我可以进一步解释 Yjs 的 StructStore / Transaction / GC 机制，或者 OT 的一个典型转换例子。