打字机大战：如何在 React 中驯服多用户协作的“混沌怪兽”
各位前端界的“代码巫师”们，大家好！
今天我们要聊的东西，听起来可能有点吓人，甚至有点像数学课本里的噩梦。但别慌，我们今天不讲微积分，我们讲的是如何在 React 里处理“多人同时打同一个字”的场景。
想象一下，你正在写一篇重要的文章，你的同事小明也在写同一篇文章。你在第 5 个字符后面加了个“的”，小明在第 5 个字符后面加了个“是”。如果你们俩谁也不看谁，最后会发生什么？就像两个坦克对轰，你的“的”撞上了小明的“是”，屏幕上可能变成“的是”或者乱码。
在单机版 React 里，这是不可能发生的，因为只有你一个人在操作。但在多用户协作（比如 Google Docs，或者在线白板）的环境下，这就是一场每天都在上演的“世界大战”。
今天，我们就来深入探讨如何在 React 中处理这种混乱，特别是使用 OT（Operational Transformation，操作转换）算法 来合并冲突的动作（Actions）。
准备好了吗？让我们把键盘敲得震天响，开始这场关于“控制权”的战争。
第一部分：React 的“单线程”幻觉与现实的差距
首先，我们要认清一个现实。在 React 的世界里，我们习惯于这种流程：
- 用户输入。
dispatch一个 Action。reducer计算新状态。- React 重新渲染。
这就像是一个只有你一个人的独奏乐团。你是指挥，你是乐手，你是观众。一切都在你的掌控之中。
但是，当多用户介入后，这个流程就被打破了。现在有了一个“上帝模式”的指挥家（服务器），以及两个拿着不同乐谱的乐手（用户 A 和用户 B）。
乐观更新（Optimistic Updates） 是我们在 React 中处理并发编辑的第一步。当你按下回车键，我们假设服务器已经接受了你的操作，直接在本地状态里改了，界面立马给个反馈。这很爽，很 React。
但是！ 现在的麻烦来了。用户 B 刚刚在同一个位置输入了一个字符。你的乐观更新把位置往后移了，而用户 B 的操作把位置往前移了。这时候，你们俩的数据就像两个纠缠在一起的 DNA 链，分不清谁是谁。
这就是我们今天要解决的：动作的冲突合并策略。
第二部分：OT 算法——把“侵略者”变成“友军”
OT（Operational Transformation）的核心思想非常简单，甚至有点“狡猾”：我不改你的操作，我把你的操作“翻译”一下，让它适应我的操作。
这就像是一个外交官。当用户 A 插入了一个字符，用户 B 的操作过来时，OT 不是把用户 B 的操作扔掉，而是问：“兄弟，你原本想插在第 5 位，但我刚才在第 5 位插了个东西，现在这里变拥挤了。为了不和你打架，你能不能往后挪挪？”
让我们用一个最简单的例子来说明。
假设文档目前是 Hello。
用户 A（你）在索引 5 处插入字符 'W'。
用户 B（小明）在索引 5 处插入字符 'R'。
场景一：你先操作，小明后操作。
- 文档：
Hello。 - 你插入
'W'-> 文档变成HelloW。 - 小明来了，他不知道你插了
'W'，他以为文档还是Hello，他想在 5 处插'R'。 - OT 转换：OT 发现，小明想插入的位置（5），现在实际上是在
'W'之前。所以，小明的操作必须向后偏移。 - 结果：小明在 6 处插入
'R'。文档变成HelloWR。
场景二：小明先操作，你后操作。
- 文档：
Hello。 - 小明插入
'R'-> 文档变成HelloR。 - 你来了，你想在 5 处插
'W'。 - OT 转换：OT 发现，你原本想插入的位置（5），实际上是在
'R'之前。但是，因为'R'是插入操作，它占据了空间。 - 结果：你需要在 6 处插入
'W'。文档变成HelloRW。
这就是 OT 的魔法。它保证了最终的一致性，而且保留了两个用户的操作顺序。
第三部分：代码实战——构建一个基于 OT 的 React Reducer
光说不练假把式。我们要把 OT 算法塞进 React 的 useReducer 里面。
为了简化演示，我们假设我们的文档是一个简单的字符串数组（或者字符串）。我们定义 Action 的类型。
// 定义操作类型
type Operation = {
id: string; // 操作的唯一标识，用于追踪
type: 'INSERT' | 'DELETE';
position: number;
char?: string;
};
// 定义全局状态
type State = {
document: string;
localLog: Operation[]; // 本地已经发送成功的操作日志
remoteLog: Operation[]; // 远程（小明）的操作日志
};
// 初始状态
const initialState: State = {
document: 'Hello World',
localLog: [],
remoteLog: [],
};现在，我们的 reducer 需要具备两个能力：
- 应用操作：把一个操作应用到当前的文档上。
- 转换操作：这是 OT 的核心。把一个操作转换，以适应另一个操作。
1. 应用操作
这是最简单的部分，就像在字符串上做手术。
const applyOperation = (doc: string, op: Operation): string => {
if (op.type === 'INSERT') {
// 注意：这里需要处理 position 越界的情况
const pos = Math.min(op.position, doc.length);
return doc.slice(0, pos) + (op.char || '') + doc.slice(pos);
} else if (op.type === 'DELETE') {
// 删除操作比较麻烦，因为删除一个字符后，后面的字符索引都会变。
// 简单起见，我们假设 position 是要删除的字符的索引。
const pos = Math.min(op.position, doc.length - 1);
return doc.slice(0, pos) + doc.slice(pos + 1);
}
return doc;
};2. 转换操作
这是最烧脑的部分。我们需要根据目标操作（Target，即当前文档已经存在的操作）来调整源操作（Source，即新来的操作）。
让我们写一个 transform 函数。它接收两个操作，返回转换后的操作。
const transform = (sourceOp: Operation, targetOp: Operation): Operation => {
// 如果操作类型不同，且位置有重叠，通常需要特殊处理（比如移动操作）。
// 为了代码简洁，我们这里只处理 INSERT 和 INSERT，以及 DELETE 和 DELETE 的情况。
if (sourceOp.type === targetOp.type) {
// 情况 A：两个都是插入操作
if (sourceOp.position < targetOp.position) {
// 如果源操作在目标操作之前，且目标操作还没发生，那么源操作的位置保持不变。
// 比如：源(位置5) -> 目标(位置10)。源不需要动。
return { ...sourceOp };
} else if (sourceOp.position > targetOp.position) {
// 如果源操作在目标操作之后，且目标操作还没发生，
// 那么源操作必须往后挪，因为目标操作插了个东西进来，把空间撑大了。
// 比如：源(位置10) -> 目标(位置5)。源现在变成位置11。
return { ...sourceOp, position: sourceOp.position + 1 };
}
} else {
// 情况 B：一个是插入，一个是删除（最经典的冲突）
// 假设 sourceOp 是 INSERT，targetOp 是 DELETE
if (sourceOp.type === 'INSERT' && targetOp.type === 'DELETE') {
// 场景：你想在位置5插入字符，但有人要在位置5删除字符
if (sourceOp.position < targetOp.position) {
// 你插在删的前面。比如：你(5) -> 删(10)。
// 删还没发生，你的插入位置不受影响。位置5还是5。
return { ...sourceOp };
} else if (sourceOp.position > targetOp.position) {
// 你插在删的后面。比如：你(10) -> 删(5)。
// 删还没发生。删掉位置5后，整个字符串变短了，你的插入位置应该往前挪一位？
// 不，OT的逻辑是：如果源操作在目标操作之后，源操作的位置应该增加（+1）。
// 为什么？因为目标操作（删除）是在源操作之后执行的。
// 1. 当前文档长度 L。
// 2. 执行你(位置10)。
// 3. 执行删(位置5)。
// 删掉位置5后，长度变成 L-1。原来的位置10现在变成了位置9。
// 所以，为了在最终的文档里保持位置10，我们需要在源操作里把位置写成 11。
return { ...sourceOp, position: sourceOp.position + 1 };
} else {
// 惊！你在位置5插入了，他在位置5删除了。
// 这取决于谁先发生。
// 如果目标是删除，意味着文档里本来有个东西在位置5被删了。
// 如果源是插入，意味着你要在那儿加个东西。
// 如果删先发生，那个东西没了，你插入的内容保留。
// 如果你先发生，你插了，然后他删了。通常 OT 策略是：删除操作会吞噬插入操作。
// 也就是你的插入无效了。
// 在这个简单的实现里，我们假设：如果位置完全重合，删除操作优先级更高（或者合并）。
// 这里我们简单处理：如果重合，删除操作直接吃掉插入操作。
// 返回 null 表示操作被合并/取消了。
return null;
}
}
// 假设 sourceOp 是 DELETE，targetOp 是 INSERT
if (sourceOp.type === 'DELETE' && targetOp.type === 'INSERT') {
if (sourceOp.position < targetOp.position) {
// 你删在插的前面。比如：你(5) -> 插(10)。
// 插还没发生。你删了5，文档变短了，插的位置应该减1？
// 不，OT 逻辑：源操作在目标操作之前，源操作的位置增加（+1）。
// 因为目标操作在后面插入，它把空间撑大了。
return { ...sourceOp, position: sourceOp.position + 1 };
} else if (sourceOp.position > targetOp.position) {
// 你删在插的后面。比如：你(10) -> 插(5)。
// 你删了10。插在5。
// 插在5，文档长度增加1。你的删除位置10应该减1？
// 不，OT 逻辑：源操作在目标操作之后，源操作的位置不变。
// 因为你在他后面删，他插入的内容会把你挤开。
return { ...sourceOp };
} else {
// 完全重合：你在删，他在插。
// 如果删先发生，插的内容保留。
// 如果插先发生，删的内容保留。
// 在 OT 中，这通常意味着操作合并。我们这里简化为删除优先。
return null;
}
}
}
return sourceOp;
};3. Reducer 的整合
现在，我们有了 applyOperation 和 transform，我们可以写一个健壮的 reducer 了。
这个 Reducer 的逻辑是：
- 接收一个
Action（可能是本地的，也可能是远程的）。 - 遍历操作日志。
- 如果是新来的操作，它必须先“见见世面”（与日志里的所有旧操作进行转换）。
- 如果转换后还活着，就把它应用到文档上，并存入日志。
const reducer = (state: State, action: any): State => {
// 1. 乐观更新：如果是本地操作，直接应用
if (action.isLocal) {
const newDoc = applyOperation(state.document, action.payload);
return {
...state,
document: newDoc,
localLog: [...state.localLog, action.payload],
};
}
// 2. 同步更新：如果是远程操作，需要进行 OT 转换
if (action.isRemote) {
let op = action.payload;
// 关键步骤：OT 转换
// 新来的操作必须适应所有的历史操作
// 我们遍历本地的 log，让新操作适应它们
for (const localOp of state.localLog) {
op = transform(op, localOp);
// 如果转换后 op 变成了 null（比如被删除操作吞掉了），直接返回当前状态
if (!op) {
return state;
}
}
// 然后我们还要适应远程的 log
for (const remoteOp of state.remoteLog) {
op = transform(op, remoteOp);
if (!op) {
return state;
}
}
// 如果转换成功，应用操作并记录
if (op) {
const newDoc = applyOperation(state.document, op);
return {
...state,
document: newDoc,
remoteLog: [...state.remoteLog, op],
};
}
}
return state;
};第四部分：实战演练——模拟“会议室”场景
光看代码有点枯燥。让我们构建一个完整的 React 组件，模拟两个用户在同一个文档上打字。
为了方便演示，我们这里用 setTimeout 来模拟网络延迟。
import React, { useReducer } from 'react';
// 定义类型
type State = {
document: string;
isSyncing: boolean;
};
type Action =
| { type: 'UPDATE_DOCUMENT'; payload: string }
| { type: 'SIMULATE_REMOTE_USER'; delay: number; text: string };
const initialState: State = {
document: 'Type here to start...',
isSyncing: false,
};
// 一个简单的模拟器，假装另一个用户在输入
const simulateRemoteUser = (dispatch: React.Dispatch<Action>) => {
const texts = ['Hello ', 'World!', 'This is ', 'collaboration.'];
let index = 0;
const interval = setInterval(() => {
if (index >= texts.length) {
clearInterval(interval);
return;
}
// 模拟网络延迟 1.5秒
setTimeout(() => {
dispatch({
type: 'SIMULATE_REMOTE_USER',
delay: 1500,
text: texts[index],
});
index++;
}, 1500);
}, 2000); // 每2秒发一次指令
};
const CollaborativeEditor: React.FC = () => {
const [state, dispatch] = useReducer((state: State, action: Action) => {
switch (action.type) {
case 'UPDATE_DOCUMENT':
return { ...state, document: action.payload };
case 'SIMULATE_REMOTE_USER':
// 这里我们没有写复杂的 OT 逻辑，只是演示数据流
// 在真实场景中，这里的 payload 应该是一个 Operation 对象
// 我们假设远程用户直接修改了文档（这是错误的，但在演示中为了简化）
return { ...state, document: state.document + action.text };
default:
return state;
}
}, initialState);
// 开场白
React.useEffect(() => {
simulateRemoteUser(dispatch);
}, []);
return (
<div style={{ padding: '20px', fontFamily: 'monospace' }}>
<h1>React 协作编辑器 (演示模式)</h1>
<p style={{ color: 'gray' }}>
注意：下面是一个没有冲突处理机制的简单演示。
远程用户会直接追加文本。
</p>
<div
style={{
border: '2px solid #333',
padding: '20px',
minHeight: '100px',
whiteSpace: 'pre-wrap',
marginBottom: '20px'
}}
>
{state.document}
</div>
<input
type="text"
placeholder="输入内容..."
style={{ width: '100%' }}
onChange={(e) => {
// 本地更新
dispatch({ type: 'UPDATE_DOCUMENT', payload: e.target.value });
}}
/>
<p>状态: {state.isSyncing ? '同步中...' : '空闲'}</p>
</div>
);
};
export default CollaborativeEditor;注：上面的代码是“裸奔”的。在实际生产环境中，如果远程用户直接改了文档内容，本地用户再输入，就会产生覆盖或丢失。
第五部分：进阶话题——为什么 OT 这么难？以及如何让它变得优雅？
如果你觉得上面的 transform 函数写得心惊肉跳，别担心，你的直觉是对的。OT 算法在处理“移动”操作时简直是噩梦。
移动操作：比如你把第 2 个字符“e”移到了第 5 个位置。
如果这时候，小明在“e”的位置插入了一个字符，或者删除了“e”的位置，OT 算法需要极其复杂的逻辑来重新计算“e”的新位置。这被称为“指数空间问题”，因为处理移动操作需要知道整个文档的上下文。
1. 乐观更新的陷阱
在 React 中使用 OT，最大的坑在于乐观更新。
当你输入一个字符，你立即把它加到了本地文档里。这时候，你把 localLog 更新了。
但是，网络还没回来！
如果这时候小明也输入了字符，你的 reducer 会先运行你的乐观更新，把你的操作加入 localLog。然后小明来了，小明的新操作会遍历 localLog。
问题来了：小明的新操作是遍历 localLog（你的操作），还是遍历 remoteLog？
通常的做法是：
- 双向同步：你的操作要适应小明的，小明的操作也要适应你的。
- 版本号：给每个操作加一个版本号。如果小明的新操作版本比你旧，他就适应你；反之亦然。
2. 乐观更新的回滚
如果你的乐观更新成功了，但服务器返回了“冲突”错误（这在 OT 中很少见，因为 OT 本身就是为了解决冲突的，但在某些极端边缘情况如移动操作中会发生），你该怎么办？
你需要一个回滚机制。React 的 useReducer 配合历史记录栈可以实现“时间旅行”。
type HistoryState = {
past: State[];
present: State;
future: State[];
};
// 每次成功应用操作后：
// past.push(present);
// present = newState;
// future = [];这样，如果服务器告诉你“你的操作搞砸了”，你可以直接 present = past.pop()，瞬间回到上一秒。
第六部分：CRDTs —— OT 的替代方案
在结束今天的讲座之前，我必须提到一个现代 Web 开发中越来越流行的东西：CRDTs（Conflict-free Replicated Data Types，无冲突复制数据类型）。
OT 是“命令式”的：我告诉你，我要做什么，你帮我改。
CRDT 是“声明式”的：我给你一个数据结构，它自己知道怎么合并。
比如，一个简单的 CRDT 可能是：
// 一个简单的 Set CRDT
const mySet = new Set(['A', 'B']);
const yourSet = new Set(['B', 'C']);
// 合并
const mergedSet = new Set([...mySet, ...yourSet]);
// 结果：['A', 'B', 'C']
// 没有冲突！B 出现了两次也没事，它就是一个集合。对于 React 来说，CRDTs 往往比 OT 更容易实现。你不需要写复杂的 transform 函数。你只需要把两个 CRDT 对象合并，然后渲染。
但是，CRDTs 有它的代价。它们通常消耗更多的内存，而且在处理某些特定场景（如严格的文本格式化）时，可能不如 OT 灵活。
第七部分：总结——如何选择？
回到我们的主题：React 动作的冲突合并策略。
- 如果你的应用只是简单的投票、点赞，或者数据结构是 Set/List：用 CRDTs。它们是懒人的救星，也是现代 Web 的宠儿。
- 如果你的应用是复杂的文本编辑器、代码编辑器：你需要 OT。你需要精确控制每一个字符的位移，你需要保留用户操作的语义（比如“我删除了 X，不是他删除了 X”）。
- 在 React 中实现 OT：
- 使用
useReducer作为核心逻辑控制器。 - 把操作（Actions）序列化（JSON）以传输给服务器。
- 服务器负责验证和广播。
- 客户端负责
transform和apply。 - 记得处理乐观更新，但要为回滚做好准备。
- 使用
最后，我想说，多用户协作不仅仅是技术问题，它是关于信任的问题。你的代码必须足够健壮，才能信任其他用户的输入不会破坏你的世界。OT 算法就是这种信任的数学证明。
好了，今天的讲座就到这里。现在，拿起你的键盘，去征服那个混乱的世界吧！记住，不要打架，要转换！