实时协作编辑的核心难点是多用户异步修改同一数据时如何保证最终一致性且不丢失操作；操作转换（OT）通过动态变换操作位置、合并与逆操作等机制解决该问题，但实现复杂，CRDT是其现代替代方案。
实时协作编辑（比如多人同时编辑同一份文档）的核心难点在于：不同用户在不同时间、不同网络条件下对同一份数据做修改，如何让所有人的视图最终一致且不丢失操作？操作转换（Operational Transformation, OT）是解决这个问题的经典算法，JavaScript 中的协同编辑库（如 ShareDB、Quill + OT、Yjs 的早期版本）都依赖它。
操作转换的基本思想：让本地操作“适应”远程操作
OT 不是简单地按时间顺序执行操作，而是让每个操作在应用前，根据已发生的其他操作动态调整自身——这个过程叫“变换”（transform）。关键假设是：只要所有客户端对同一组操作应用相同的变换规则，最终状态必然一致。
例如，两人同时编辑一段文本：
- 用户 A 在位置 0 插入字符 "a"（操作 Ains = { type: "insert", pos: 0, text: "a" }）
- 用户 B 在位置 0 插入字符 "b"（操作 Bins = { type: "insert", pos: 0, text: "b" }）
如果 A 先发操作，B 后发，那么 B 的操作在到达 A 时，需被“变换”：原想插在位置 0，但 A 已在 0 插了 "a"，所以 B 的插入位置应变为 1，变成 { pos: 1, text: "b" }。反之亦然。变换后双方应用的操作互不冲突，结果都是 "ab" 或 "ba"（取决于谁先提交），但内容一致、无错乱。
立即学习“Java免费学习笔记（深入）”；
核心组件：操作（Operation）、变换函数（transform）、合并（compose）与逆操作（invert）
一个典型的 OT 实现需定义三类函数：
- transform(op1, op2)：把 op1 “变换”成 op1'，使其在 op2 已执行的前提下仍语义正确。返回 [op1', op2']（双向变换，常用于同步场景）
- compose(op1, op2)：将两个连续操作合并为一个等效操作（如连续两次插入可合并，提升效率）
- invert(op)：生成撤销该操作的操作（如插入 → 删除，删除 → 插入），用于处理撤回或冲突回滚
这些函数必须满足数学上的 OT 正确性条件（如包含性、一致性），否则会出现状态分歧。实际开发中不建议手写完整 OT 引擎，而应基于成熟模型（如 Google Wave 的 JSON-OT、Text OT）构建。
JavaScript 中的典型 OT 流程（以文本编辑为例）
假设使用基于字符串的简单 OT 模型：
- 用户本地输入时，生成操作（如 insert/delete），暂存为 pending 操作
- 操作通过 WebSocket 发送到服务端；服务端广播给其他客户端
- 收到远程操作时，对本地 pending 操作逐个调用 transform，更新其位置/参数
- 将变换后的操作应用到本地副本；同时把原始操作（未变换）提交到服务端日志，作为全局有序操作序列
- 服务端也维护一份权威状态，并用相同 transform 规则协调所有进来的操作，确保因果顺序（causality）不被破坏
注意：真实系统还需处理操作丢失、重连、延迟、并发 undo 等问题，因此往往引入操作序列号（sequence number）、向量时钟（vector clock）或操作日志（operation log）来排序和去重。
现代替代方案：CRDT vs OT
OT 虽成熟，但实现复杂、难以验证。近年来，基于无序操作的 CRDT（Conflict-free Replicated Data Type） 越来越流行（如 Yjs、Automerge）。它不依赖中心服务协调操作顺序，每个操作自带逻辑时钟，靠纯函数合并，天然支持离线编辑和最终一致性。不过 CRDT 通常内存开销更大、操作表达更抽象。选择 OT 还是 CRDT，取决于场景：强实时+低延迟要求（如代码协作）仍常用 OT；高离线支持+开发者体验优先（如笔记、表单）则倾向 CRDT。
不复杂但容易忽略：无论选哪种，核心不是算法本身，而是如何让操作可序列化、可比较、可逆，以及如何在分布式网络中可靠传递和排序它们。
