当 React 遇见 OT：一场关于“文字的战争”与“DOM 的和解”
各位好，欢迎来到今天的讲座。请把你们的笔记本电脑从“Slack 消息回复模式”切换到“码农烧脑模式”。
今天我们要聊的话题，有点像是在泥泞的沼泽里造火箭。我们要构建一个实时协作编辑器。
想象一下，你正在写代码，周围坐着你的队友。你敲下一个 const，还没松开键盘，屏幕上突然出现了一个红色的波浪线，紧接着，你刚才敲的 const 被你的队友——那个正在喝咖啡的家伙——直接删掉了。更糟糕的是，他的光标正闪烁在你的 } 后面，一脸无辜地问：“咦？你怎么删了 return？”
这，就是实时协作编辑器的战场。我们要解决的，是并发控制问题。
在今天的讲座中，我将带你们深入这个领域的核心。我们将探讨如何利用 OT（Operational Transformation，操作转换）算法 处理并发冲突，然后如何利用 React 协调器 将这种冷冰冰的数学逻辑，翻译成用户眼中流畅的界面。这不是简单的 CRUD（增删改查），这是在争夺数据的“真理”。
准备好了吗？Let’s rock.
第一章：OT 算法——当你的文字被“篡改”时
首先，我们要理解为什么现有的技术做不了这个。
传统的数据库处理是“写后读”，但网络是“写前读”。在分布式系统中，时间不是线性的。当你和队友同时敲击键盘，你们的请求就像两条平行线，迟早会撞车。
这时候，OT 算法登场了。OT 算法不像 CRDT（无冲突复制数据类型）那样试图通过数学构造让数据自动“和好”，OT 算法更像是一个霸道总裁律师。
它的核心哲学是：客观真理（Document）是不可动摇的，所有的操作（Operations）都必须经过转换，以适应周围环境。
1.1 真理的奥义
在 OT 系统中，我们维护一个“服务器文档”状态。这个状态就是客观真理。
当一个用户（比如我）输入 “Hello” 时，我生成了一个操作 Op_Insert(0, "Hello")。这个操作会被发送到服务器。服务器接收后，将其应用到文档上，然后广播给所有用户（包括你）。
1.2 转换的艺术
现在，轮到你了。你也在输入，你也生成了一个操作 Op_Insert(0, "Hi")。但是，在你生成操作并发送之前，我刚才的操作 Op_Insert(0, "Hello") 已经到达了服务器，并被应用了。
服务器现在告诉你的客户端：“嘿，别急着按回车，你的操作有个邻居叫‘Hello’。”
你的客户端收到一个通知：your_op.transform(my_op)。
这就叫转换。
比如，我在第 0 个位置插入了 “Hello”（长度 5），而你想在同一个位置插入 “Hi”（长度 2）。
如果不转换，你的 “Hi” 会插在 “Hello” 前面，结果是 “HiHello”。
但服务器端已经是 “Hello” 了。
为了让你看到和我一样的效果，你的客户端必须执行转换：你的插入位置应该变成 +5。
如果你是在 “Hello” 之后插入，比如我在 5 位置插入了 “World”，而你在 5 位置插入了 “There”，转换后，你的位置会变成 6。你的 “There” 会插入在 “World” 后面。
这就是 OT 的魔法。它保证了，无论网络延迟多少，无论谁先谁后，最后屏幕上呈现的文档永远是一致的。
代码示例：一个极简的 OT 转换器
// 为了让代码能跑起来，我们用一种非常原始的方式模拟 OT
class Operation {
constructor(index, text) {
this.index = index;
this.text = text;
}
}
// 模拟服务器端的一个基础转换函数
// 这里的逻辑非常抽象，但却是协作编辑器的基石
function transform(op1, op2) {
// 简单的 OT 转换规则：
// 如果两个操作都在同一个位置，且方向相反，我们需要计算长度偏移
const op1Start = op1.index;
const op2Start = op2.index;
const op1Len = op1.text.length;
const op2Len = op2.text.length;
// 情况 A: op1 在 op2 前面，且无重叠
if (op1Start + op1Len <= op2Start) return new Operation(op1.index, op1.text);
// 情况 B: op2 在 op1 前面，且无重叠
if (op2Start + op2Len <= op1Start) return new Operation(op2.index, op2.text);
// 情况 C: 重叠区域——这是我们要处理的核心
if (op1Start < op2Start) {
// op1 在前，op2 在后。op2 的 index 需要被推后。
// 推后多少？取决于 op1 的长度。
return new Operation(op2.index + op1Len, op2.text);
}
// 情况 D: op2 在前，op1 在后。op1 的 index 需要被推后。
return new Operation(op1.index + op2Len, op1.text);
}
// 场景模拟
const doc = "Hello"; // 初始文档
// 我输入 " World"
const myOp = new Operation(5, " World");
// 你在此时输入 "Hi"
const yourOp = new Operation(0, "Hi");
// 你的客户端收到我的操作通知，你需要对你的操作进行转换
const correctedYourOp = transform(yourOp, myOp);
console.log("你的原始意图:", yourOp); // { index: 0, text: 'Hi' }
console.log("转换后的意图:", correctedYourOp); // { index: 5, text: 'Hi' }
// 最终结果: "Hi World"好，OT 的逻辑我们已经烂熟于心了。但这只是后台的数学游戏。如果数学正确，但 UI 爆炸了，那这个编辑器也是废品。
接下来，我们要请出今天的另一位主角：React。
第二章：React 协调器——虚拟 DOM 的内心独白
React 的魅力在于声明式。你不需要告诉它“怎么改”，你只需要告诉它“变成了什么”。然后 React 的协调器会自动计算“怎么改”。
对于我们的编辑器来说，React 协调器需要做的，就是根据 OT 算法生成的最新文档状态，计算出 DOM 的变化。
2.1 纯文本 Diff 的局限性
如果你只是简单地使用 React 渲染一个 <textarea>，那你做得毫无意义。为什么？因为 <textarea> 本质上是一个原生组件，它没有内部状态。每次 React 更新它，都会导致整个输入框清空，光标丢失。
我们要渲染的是富文本，或者至少是字符级别的精细控制。
这意味着，我们不能把整个文档当作一个字符串。我们要把文档看作一个树（树状结构），或者至少是线性的节点列表。
React 的协调器会遍历旧的虚拟 DOM 树和新的虚拟 DOM 树，进行比对。
- Type Change: 比如从
<span>变成了<p>。React 会暴力卸载旧的，挂载新的。 - Props Change: 比如
<span className="red">变成了<span className="blue">。React 会更新 DOM 属性。 - Text Content Change: 比如 “abc” 变成了 “abd”。React 会更新文本节点。
对于编辑器来说，如果我们每次按键都触发全量 Diff，性能会极其糟糕。想象一下，如果你在一个 1 万字的文档里打了一个字，React 需要遍历这 1 万个字符的节点。这太慢了，用户体验会像蜗牛一样。
2.2 协调器的优化：局部更新
我们要利用 React 的 Fiber 架构。Fiber 允许 React 将渲染工作拆分成一个个小单元（Fiber 节点）。
在我们的 OT + React 架构中，协调器的策略应该是：
- 增量更新： 当 OT 更新文档时，我们不应该重绘整个树。我们只计算发生了变化的那个节点。
- 批量处理： 如果用户连续快速敲击键盘，React 会将这些更新放在同一个事件循环批次中处理，避免多次重绘。
第三章：深度融合——如何把 OT 变成 React 的 State
现在，我们要解决最棘手的问题：数据流。
通常的做法是：
- 用户输入 -> 生成 OT 操作 -> 发送到服务器。
- 服务器接收 -> 转换其他操作 -> 应用操作 -> 更新全局文档状态。
- 全局文档状态更新 -> 触发 React 组件
render()。
但是，如果我们只在服务器确认后才更新 UI，那叫“延迟”，不叫“实时”。用户会有卡顿感。我们需要 乐观 UI（Optimistic UI）。
3.1 乐观 UI 的实现
当我们按下按键时，我们假设操作会成功。
- 用户输入: 本地生成
Op_Insert。 - 立即更新: 将
Op_Insert应用到本地的文档状态（OT 文档）。 - 渲染: React 协调器根据新的文档状态渲染 UI。
- 传输: 将操作发送到服务器。
- 冲突处理: 如果服务器返回转换后的操作（因为我们之前的假设可能错了），我们撤销本地操作，应用服务器的新操作。
代码示例：React 组件与 OT 状态的交互
import React, { useState, useEffect, useRef } from 'react';
// 这是一个模拟的 OT 文档类，实际上你需要更复杂的实现
class TextDocument {
constructor(initialText) {
this.content = initialText;
}
insert(index, text) {
this.content = this.content.slice(0, index) + text + this.content.slice(index);
return this;
}
}
const CollaborativeEditor = () => {
const [docState, setDocState] = useState(new TextDocument("Welcome to the future..."));
const [isRemote, setIsRemote] = useState(false);
// 这是一个模拟的“输入缓冲区”，用于处理远程光标
const inputBufferRef = useRef([]);
const handleKeyDown = (e) => {
if (e.key === 'Enter') return; // 简单起见，不处理回车
// 1. 乐观更新
const newDoc = docState.insert(e.target.selectionStart, e.key);
setDocState(newDoc);
// 2. 模拟网络请求
setTimeout(() => {
console.log("Sending operation to server...");
// 在真实场景中，这里会发送 { index, text } 给 WebSocket
}, 100);
};
// 这是一个模拟的“远程更新”逻辑
// 当服务器推来一个新的操作时，我们需要应用它
const handleRemoteUpdate = (index, text) => {
// 这里的逻辑必须考虑当前的 selectionStart
// 如果远程在 5 插入，而我们当前的焦点在 6，我们的插入点实际上变成了 7
// 这就是 OT 的复杂性所在。
const currentCursor = inputBufferRef.current.length;
// 简单的修正：如果远程操作在我们当前光标之前，我们需要调整光标位置
// 这是一个极其简化的逻辑，实际 OT 库会处理这些
let adjustedIndex = index;
if (index < currentCursor) {
adjustedIndex += 1;
}
setDocState(prev => prev.insert(adjustedIndex, text));
};
return (
<div className="editor-container">
<h2>React OT Editor Demo</h2>
<p>State: {docState.content}</p>
<p>Local Cursor: {inputBufferRef.current.length}</p>
<textarea
value={docState.content}
onChange={(e) => {
// 这里只是演示，实际上我们不应该直接 onChange 更新 OT 文档
// 我们应该记录文本差异并生成 Operation
// 为了演示简单，这里省略 Diff 计算
setDocState(new TextDocument(e.target.value));
}}
onKeyDown={handleKeyDown}
ref={(textarea) => {
if(textarea) inputBufferRef.current = textarea.selectionStart;
}}
/>
</div>
);
};
export default CollaborativeEditor;上面的代码展示了基本的思路。但如果你以为这就完了，那你离“资深专家”还差一个图书馆。
第四章：架构的深度解析——协调器不仅仅是渲染
在真正的生产级应用中，React 的协调器必须处理一些非常反直觉的问题。
4.1 输入缓冲
想象一下，你的网速突然变慢了。用户疯狂地敲击键盘，你疯狂地更新本地状态。这时，服务器终于传来了上一步的操作。如果你直接渲染，屏幕上的文字会疯狂闪烁，就像出现故障的电视信号。
解决方案：输入缓冲。
我们在本地维护一个“输入缓冲区”。用户的操作被推送到这个缓冲区。React 协调器只渲染缓冲区的内容。当服务器确认操作后，我们清空缓冲区，渲染最终文档。
这就像浏览器处理 input 事件一样，它不会在每次按键都立刻重绘整个页面，而是积累输入内容，直到下一次重绘周期。
4.2 光标同步与虚拟光标
在协作编辑中，我们不仅要同步文字，还要同步光标。如果张三的光标停在 “Hello”，李四的光标停在 “World”，UI 必须在张三的位置画一个绿色框，在李四的位置画一个红色框。
React 是如何做到的？
我们不能直接在 <textarea> 上画框，因为原生控件不支持。我们必须把 <textarea> 的 value 转换成一个 React 的 Virtual DOM Tree，然后把光标渲染在对应的 <span> 上。
这就像把纯文本变成了一个巨大的 HTML 结构。
代码示例：光标与节点的融合
const TextComponent = ({ text, cursorPos, isSelected }) => {
return (
<span className={isSelected ? "cursor-highlight" : ""}>
{text}
</span>
);
};
// 这里的逻辑是将 OT 文档映射为 React 树
// 注意：在大型应用中，这需要极度优化，不能每输入一个字就生成一个新的树
const renderText = (content, cursorPos) => {
// 简单粗暴的字符串分割，实际应用中会使用更高效的数据结构如 Array
const characters = content.split('');
return (
<div className="text-container">
{characters.map((char, index) => (
<TextComponent
key={index} // 虽然这里用 index 做 key 不推荐，但在简单演示中为了说明逻辑
text={char}
isSelected={index === cursorPos}
/>
))}
</div>
);
};这段代码揭示了一个残酷的事实：将 React 的声明式渲染与基于字符的 OT 算法结合，会导致极高的渲染开销。
为了解决这个问题，React 团队引入了 key 的概念和 Fiber。协调器会尝试复用节点。如果只是光标移动（isSelected 状态改变），React 会尝试只更新 className，而不是销毁整个 DOM 树。
第五章：实战中的挑战与权衡
写代码就像谈恋爱，你会遇到很多磨合期的问题。
5.1 文本换行与位置计算
OT 算法通常基于“字符索引”。但在 HTML 中，一个字符可能占据多个像素，或者因为换行符的存在，占据多行。
当你在第 5 个字符处插入内容，如何知道它在屏幕上是在哪一行？这涉及到文本布局引擎的计算。如果你的 React 组件里有很多 <br> 或者复杂的 CSS，定位光标会变得非常复杂。
专家建议： 尽量使用基于文档结构的表示法（如 JSON 或 XML），而不是纯字符串。React 处理 JSON 树的 Diff 比处理字符串要容易得多。将文本树化，光标就可以定位到具体的 JSON 对象上。
5.2 性能陷阱：React 的 Diff 算法并不总是完美的
React 的 Diff 算法默认是“同层比较”。如果两个兄弟节点的位置发生了交换，React 会认为它们是不同的节点，从而销毁重建。
在编辑器中，如果我们频繁地插入节点，React 可能会陷入性能黑洞。
优化策略：
- 扁平化渲染： 不要嵌套太多层 div。直接使用一个列表，每个列表项对应文档中的一个块（如一个段落）。
- 虚拟滚动： 如果文档有 100 万字，不要渲染前 100 万字。只渲染可视区域内的那几十行。这是长列表渲染的通用原则。
5.3 乐观更新与回滚
乐观更新是用户体验的杀手锏，也是 Bug 的温床。
如果你的用户正在输入，突然网络断开，或者触发了复杂的冲突转换，你的本地状态可能会被服务器覆盖。如果服务器返回的操作导致光标位置乱飞（比如从 10 变成了 100），用户会感到非常困惑。
最佳实践：
实现一个“本地操作队列”。当接收到远程转换操作时，不要直接覆盖本地状态。先检查转换后的结果是否合理。如果操作冲突极其严重（比如导致光标跳出了文档边界），则弹出提示框询问用户是否接受远程更改，或者自动撤销本地输入。
第六章：React Fiber 与协作编辑的未来
React 16 引入了 Fiber 架构。这不仅仅是渲染优化，它为协作编辑器提供了新的可能。
Fiber 是一个执行单元。它可以被打断。这意味着，React 可以在处理大量文本更新的同时，暂停一下，去处理网络请求，或者去计算下一个渲染帧。
想象一下这样一个架构：
- OT Core: 纯数学运算，不涉及 DOM 操作。
- Fiber Renderer: 接收 OT Core 的输出，执行 Diff，更新 DOM。
- Scheduler: 调度器。
现在，我们可以利用 Fiber 的 suspense 特性。如果服务器操作正在处理中，React 可以展示一个“正在同步…”的占位符。一旦数据到达，DOM 瞬间更新。
这比传统的轮询（Polling）或长轮询（Long Polling）要高效得多，因为它利用了 React 的渲染管线。
第七章：代码重构——打造一个健壮的架构
最后，让我们把所有的碎片拼凑起来。我不会给完整的代码，因为那是几百个文件的工作量。但我会给一个架构骨架。
核心思想： 状态（OT 文档）与视图（React 树）必须解耦。
// 1. 纯数学层：OT Engine
class OTDocument {
constructor(text) { this.text = text; }
// ... insert, delete, transform methods
}
// 2. 协调层：将 OT 文档转换为 React Props
const mapOTToReact = (otDoc) => {
return otDoc.text.split('').map((char, index) => ({
id: index, // 唯一 ID
char: char,
// 这里可以加入光标位置、作者信息等元数据
}));
};
// 3. 表现层：React 组件
const RichTextEditor = () => {
const [doc, setDoc] = useState(new OTDocument("Start typing..."));
const [cursor, setCursor] = useState(0);
// 乐观更新
const handleInput = (e) => {
const newValue = e.target.value; // 实际应用中应该计算 diff 生成 Op
const newDoc = new OTDocument(newValue);
setDoc(newDoc);
setCursor(e.target.selectionStart);
};
// 渲染逻辑
const nodes = mapOTToReact(doc);
return (
<div className="editor">
{nodes.map(node => (
<span
key={node.id}
style={{ color: node.id === cursor ? 'blue' : 'black' }}
>
{node.char}
</span>
))}
</div>
);
};看，这就是平衡的艺术。OTDocument 负责处理混乱的网络世界和逻辑冲突，保持数据的“正确性”。React 负责处理视觉呈现，保持用户的“愉悦感”。
结语：不仅仅是技术，更是哲学
我们今天探讨了实时协作编辑器的构建。这不仅仅是关于 React 和 OT。
- OT 告诉我们要诚实地面对历史：每一个操作都有因果，每一个冲突都需要转换。
- React 告诉我们要优雅地面对变化：不要去改变过去，去构建未来。
- 协调器则是那个在两者之间传递信息的信使。
构建这样一个编辑器，你是在和延迟赛跑，是在和人类的直觉博弈，是在和数据结构调情。
当你最后看到两个光标在屏幕上同时移动，当你在编辑器里看到队友的名字伴着光标闪烁，你会明白这一切的努力都是值得的。那不仅仅是代码，那是远程连接的体温。
现在，去写代码吧，别让你的队友等太久了。