概述#

撤销和重做几乎是所有编辑类产品的基础能力，但它恰恰是那种”做一个能用的版本只要半天，做一个真正经得起折腾的版本要反复打磨好几个迭代”的功能。无论你做的是图形画布（类似 Figma、白板、流程图）还是富文本编辑器（类似 Notion、飞书文档、各种 CMS 后台），背后的核心问题是一样的：如何精确地、可逆地描述用户对文档做的每一次改动，并且让这种回退在用户感知上是”自然”的。

它的本质是对”状态变化”建模——你要么记录状态本身，要么记录引起状态变化的操作，要么记录两者之间的差异。本文主要就这些展开阐述

一、“撤销”到底在撤销什么#

动手之前先注意一个问题：编辑器把”文档状态”建模成了什么？撤销的本质就是在状态空间里来回移动，所以状态的建模方式直接决定了 undo/redo 的实现难度。

比如说文档是一棵结构化的数据树（比如画布里的图元数组、富文本里的文档节点树），那么撤销就是让这棵树回到上一个版本。如果你的文档状态散落在各处——一部分在 React state 里，一部分在 DOM 里，一部分在某个全局单例里——那么撤销就会变成一场灾难，因为你永远没法保证回退是完整的。于是做撤销写撤销逻辑之前，需要先把文档状态收敛成一个清晰、可序列化、单一来源的数据结构。

二、几种主流思路#

撤销机制大体上分多个流派

1
class SnapshotHistory<T> {
2
    private undo: T[] = [];
3
    private redo: T[] = [];
4
    constructor(
5
        private getState: () => T,
6
        private setState: (s: T) => void,
7
    ) {}
8

9
    commit() {
10
        this.undo.push(structuredClone(this.getState()));
11
        this.redo = [];
12
    }
13
    undoOnce() {
14
        if (!this.undo.length) return;
15
        this.redo.push(structuredClone(this.getState()));
16
        this.setState(this.undo.pop()!);
17
    }
18
    redoOnce() {
19
        if (!this.redo.length) return;
20
        this.undo.push(structuredClone(this.getState()));
21
        this.setState(this.redo.pop()!);
22
    }
23
}

1
interface Command {
2
    execute(): void;
3
    undo(): void;
4
    redo(): void;
5
}
6

7
class AddElementCommand implements Command {
8
    constructor(
9
        private store: Store,
10
        private el: CanvasElement,
11
    ) {}
12
    execute() {
13
        this.store.add(this.el);
14
    }
15
    undo() {
16
        this.store.remove(this.el.id);
17
    }
18
    redo() {
19
        this.execute();
20
    }
21
}
22

23
class UpdateElementCommand implements Command {
24
    constructor(
25
        private store: Store,
26
        private id: string,
27
        private before: Partial<El>,
28
        private after: Partial<El>,
29
    ) {}
30
    execute() {
31
        this.store.patch(this.id, this.after);
32
    }
33
    undo() {
34
        this.store.patch(this.id, this.before);
35
    }
36
    redo() {
37
        this.execute();
38
    }
39
}

1
class CompositeCommand implements Command {
2
    constructor(private children: Command[]) {}
3
    execute() {
4
        this.children.forEach((c) => c.execute());
5
    }
6
    undo() {
7
        [...this.children].reverse().forEach((c) => c.undo());
8
    }
9
    redo() {
10
        this.children.forEach((c) => c.redo());
11
    }
12
}

三、撤销的颗粒度：一次撤销应该回退多少#

这是最影响”自然感”的一点，也是最容易被忽略的一点。技术上每一次状态变更都可以是一个撤销单元，但用户心智里的”一步”和程序里的”一次变更”几乎从来不是一一对应的。

举几个典型的例子。用户在文本里连续敲了一句话，他按下 Ctrl+Z 时期望的多半是删掉刚打的这一整个词或这一句，而不是一个字符一个字符地往回退；如果每个字符都是独立的撤销点，用户会按到崩溃。反过来，用户拖动一个图元时，鼠标移动过程中坐标可能变化了上百次，但这显然应该合并成”移动了一次”这一个撤销单元，而不是一百个。再比如，某些复合操作——“删除一个段落”在内部可能触发了”移除节点 + 调整后续节点序号 + 更新目录”等好几个子动作——对用户而言它就是一步，撤销时必须整体回退。

解决这个问题的手段主要有三类。 一是事务（transaction）：用一个显式的边界把若干底层变更包成一个原子的撤销单元，比如 history.batch(() => { ...一堆改动... })，里面发生多少次变更都只产生一个撤销点，复合操作一律用事务包起来。 二是合并（coalescing / merging）：对连续发生的同类操作做时间上的归并，典型策略是给操作打时间戳，如果新操作和栈顶操作类型相同、目标相同、且间隔小于某个阈值（比如几百毫秒到一秒），就把它们合并成一个，连续打字、连续拖动、连续调整滑块都适合这种处理。三是显式断点：在某些语义边界主动切断合并，比如用户敲了空格、回车、或者把光标移到了别处，就强制结束当前的合并窗口，让下一次输入成为新的撤销点——这正是大多数文本编辑器”按词撤销”的实现方式。

颗粒度需要拿真实使用场景去调，撤销单元应该对齐用户的意图，而不是对齐你的数据结构。

四、选区和视图状态#

撤销有时候回退的不只是文档内容，还有用户当时的”上下文”。设想用户删掉了一段文字然后撤销，如果光标没有回到那段文字所在的位置、那段文字也没有重新被选中，用户就得自己去找”我刚才在哪”，这种体验是割裂的。在画布里也一样，撤销一次删除操作后，被恢复的图元最好重新处于选中态，并且视口最好能滚动到它可见的位置。

所以撤销单元里除了文档变更，通常还应该一并记录操作前后的选区 / 光标状态。撤销时恢复”操作前”的选区，重做时恢复”操作后”的选区。这部分状态不属于文档本身，但它对自然感的贡献非常大，很多团队是在用户反馈”撤销之后找不着北”之后才补上的，不如一开始就考虑进去。需要注意的是选区状态有时会因为内容变化而失效（比如撤销恢复的节点 id 变了），所以恢复选区时要做好兜底，定位不到就退化到一个合理的默认位置，而不是抛错。

五、以画布编辑器为例子的具体实践#

图形画布的好处是它的文档模型通常比富文本干净——大多就是一个图元列表或一棵场景树，每个图元有自己的 id、坐标、尺寸、样式等属性。在这种结构上做撤销相对舒服。

如果走快照式，配合不可变更新会很顺：每次操作产生一份新的场景树，结构共享让没动的图元复用内存，撤销栈里存的就是这些树的引用。如果走命令式，你需要为每类编辑定义操作和逆操作——新增图元的逆是删除，删除的逆是带着完整属性重新插入（所以删除操作里必须把被删图元的全部数据存下来，否则没法还原），移动的逆是移回原坐标，改样式的逆是改回旧值。这里有个容易踩的坑：逆操作所需的信息必须在操作发生时就捕获好。比如删除一个图元，你不能等撤销的时候才去问”它原来长什么样”，那时它已经没了，所以要在执行删除的那一刻把它的快照塞进操作对象。

画布场景里特别需要处理好拖拽和连续变换的合并。用户拖动、缩放、旋转时会高频产生中间状态，正确做法是在交互开始时（mousedown）记下初始状态，交互过程中只更新视图不入栈，等交互结束时（mouseup）才把”从初始到最终”这一整段作为一个撤销单元提交。换句话说，撤销栈应该记录交互的结果，而不是交互的过程。

另外画布里常有一些不该进撤销历史的状态变化，比如纯粹的视口平移和缩放、图元的临时高亮、辅助线的显隐。判断标准是：这个变化算不算用户对”文档内容”的修改？只有内容性的改动才进历史，视图性的、临时性的状态不要污染撤销栈，否则用户会发现自己按了好几次 Ctrl+Z 文档却一动不动，只是画面在缩放。这里更稳的做法不是在入栈口设卡过滤，而是在数据建模阶段就把文档状态（图元的坐标、尺寸、样式、层级，需要持久化、需要协同的内容）和会话状态（视口、选中、悬停高亮、辅助线、拖拽中间态，刷新即丢、别人不需要知道）分成两条独立通道，让撤销系统从源头就只订阅文档状态那一棵树。

六、以富文本编辑器为例的具体实践#

富文本是撤销机制里最难啃的一块，难点几乎全部来自 contenteditable。浏览器原生的 contenteditable 自带一套撤销栈（也就是 document.execCommand('undo')），但它基本不可控、跨浏览器行为不一致，而且一旦你用 JavaScript 直接改了 DOM，原生撤销栈就会和修改脱节直接乱掉。 所以现代富文本编辑器几乎无一例外地选择接管撤销：自己维护一个独立于 DOM 的文档数据模型（document model），所有编辑都先作用在这个模型上，再由框架把模型渲染成 DOM；撤销操作的是模型而不是 DOM。这也是 ProseMirror、Slate、Lexical、Quill 这些主流框架的共同设计——它们都有自己的文档结构和自己的历史模块，并且会主动屏蔽浏览器原生撤销。

其实完全可以用这些框架自带的历史能力，因为它们已经把无数边界情况处理过了。 如果确实要自己实现的话还是要注意几个点：

文本输入的合并，连续打字应该合并成按词撤销，所以你需要在历史模块里实现输入的归并逻辑，并在空格、换行、光标跳转、格式切换等语义边界处断开。富文本里的”格式操作”（加粗、改颜色、设标题）和”内容操作”（插入删除文字）通常应该是不同的合并组，用户连续打字时不希望中间穿插的一次加粗被一起撤销掉。

输入法（IME）。中文、日文、韩文用户通过输入法组词时，会触发一连串 compositionstart、compositionupdate、compositionend 事件，组词过程中的中间态绝对不能各自入栈，否则撤销会把用户带回半成品的拼音状态，体验非常糟糕。正确做法是在 composition 期间挂起历史记录，等 compositionend 真正确认输入之后，才把这一整段组词作为一个撤销单元提交。

选区恢复。因为文档结构变化后，原来的选区坐标可能完全失效。主流框架的做法是用一套与具体 DOM 解耦的位置表示（比如基于文档节点路径和偏移量的”position mapping”），在文档变换时把旧位置映射到新位置，撤销时再据此还原光标。自己实现的话，至少要保证撤销后光标落在一个合理且稳定的位置，而不是莫名其妙跳到文档开头。

七、传统手段下的一些工程细节#

副作用和异步操作。如果某个编辑动作除了改文档还触发了网络请求、文件上传、或者修改了文档之外的外部资源，那么”撤销文档”并不能撤销那些副作用。处理原则是尽量让进入历史的操作是纯粹的、对文档模型的同步变更；把网络请求、持久化等副作用从撤销路径里剥离出去，作为模型变更的下游反应来处理，而不是让它们成为撤销单元的一部分。否则用户撤销一次，要去思考”那个已经上传成功的图片要不要删”这种很难有正确答案的问题。

内存管理。无论快照式还是命令式，历史栈都不能无限增长，通常要设一个上限（比如保留最近一两百步），超过就丢弃最老的记录。快照式尤其要注意，哪怕有结构共享，长时间编辑积累的快照也可能可观，可以做”定期合并旧快照”或”只保留近期细粒度、远期粗粒度”的分层策略。

任何新的编辑动作都应该清空 redo 栈。用户撤销了几步之后又开始打字，这时之前那条”重做”的分支就失去了意义，必须丢弃，否则重做会把文档带到一个和当前编辑逻辑冲突的状态。这是几乎所有编辑器都遵守的标准行为，但自己实现时很容易漏掉。

撤销 / 重做这种功能极其依赖测试，而且很难靠手测覆盖全。还是要写一份充分的自动化测试，“随机生成一串操作，全部撤销后断言文档回到初始状态、全部重做后又回到最终状态”这类性质测试（property-based testing），看能不能揪出那些手工很难想到的逆操作错误。

八、协同编辑会彻底改变撤销的含义#

单机撤销的世界是干净的：文档只有一条时间线，撤销就是沿着这条线往回走。多人协作彻底打破了这个前提——文档的时间线变成了多个用户的操作交织在一起的一条公共历史，而每个用户心里却各自有一条”我自己做过什么”的私有时间线。撤销机制的全部难度，都来自于如何在这条交织的公共历史上，正确地撤掉某个用户的某一步，同时不破坏别人的工作。

1
本地编辑 → 改 Yjs 文档 → 1) 本地渲染  2) 编码成 update 广播
2
收到远端 update → 合并进 Yjs 文档 → 重新渲染
3
Ctrl+Z → UndoManager.undo() → 只回退本客户端的变更 → 触发渲染 + 广播

1
import * as Y from "yjs";
2

3
const ydoc = new Y.Doc();
4
// 整张画布：key 是图元 id，value 是描述图元的 Y.Map
5
const yShapes = ydoc.getMap("shapes");
6

7
function addShape(shape) {
8
    // 用事务包裹，保证这是一个原子的撤销单元
9
    ydoc.transact(() => {
10
        const yShape = new Y.Map();
11
        yShape.set("x", shape.x);
12
        yShape.set("y", shape.y);
13
        yShape.set("w", shape.w);
14
        yShape.set("h", shape.h);
15
        yShape.set("fill", shape.fill);
16
        yShapes.set(shape.id, yShape);
17
    }, /* origin */ localOrigin);
18
}

1
const localOrigin = { user: myUserId }; // 本地变更统一用这个 origin
2

3
const undoManager = new Y.UndoManager(yShapes, {
4
    trackedOrigins: new Set([localOrigin]), // 只追踪本地来源
5
    captureTimeout: 500, // 500ms 内的连续变更合并为一个撤销单元
6
});
7

8
// 撤销 / 重做
9
function undo() {
10
    undoManager.undo();
11
}
12
function redo() {
13
    undoManager.redo();
14
}

1
let dragStart = null;
2

3
function onPointerDown(shapeId, pt) {
4
    const yShape = yShapes.get(shapeId);
5
    dragStart = { x: yShape.get("x"), y: yShape.get("y"), px: pt.x, py: pt.y };
6
}
7

8
function onPointerMove(shapeId, pt) {
9
    // 只更新会话状态 → 实时渲染，不碰 Yjs，不入栈，不广播
10
    sessionStore.setGhostPosition(shapeId, {
11
        x: dragStart.x + (pt.x - dragStart.px),
12
        y: dragStart.y + (pt.y - dragStart.py),
13
    });
14
}
15

16
function onPointerUp(shapeId) {
17
    const ghost = sessionStore.getGhostPosition(shapeId);
18
    ydoc.transact(() => {
19
        const yShape = yShapes.get(shapeId);
20
        yShape.set("x", ghost.x);
21
        yShape.set("y", ghost.y);
22
    }, localOrigin); // 一次事务 = 一个撤销单元
23
    undoManager.stopCapturing(); // 让这次拖拽成为独立的一步
24
    sessionStore.clearGhost(shapeId);
25
}

1
// 本地文档变更 → 广播
2
ydoc.on("update", (update, origin) => {
3
    if (origin === "remote") return; // 别把远端来的又发回去
4
    network.broadcast(encodeUpdate(update));
5
});
6

7
// 收到远端增量 → 合并（注意origin 标成 remote，不会进本地撤销栈）
8
network.onMessage((update) => {
9
    Y.applyUpdate(ydoc, decodeUpdate(update), "remote");
10
});
11

12
// 任何文档变化都触发重渲染（本地、远端、撤销都会走到这）
13
yShapes.observeDeep(() => renderCanvas(yShapes));

1
undoManager.on("stack-item-added", (event) => {
2
    event.stackItem.meta.set("selection", sessionStore.getSelection());
3
});
4
undoManager.on("stack-item-popped", (event) => {
5
    const sel = event.stackItem.meta.get("selection");
6
    if (sel) sessionStore.restoreSelection(sel); // 定位不到时内部要兜底
7
});

1
inv' = inv
2
for c in [c1, c2, ..., cn]:        # op 之后发生的每一个操作
3
    inv' = transform(inv', c)      # 把逆操作"推进"到当前状态
4
apply(inv')                        # 应用变换后的逆操作
5
broadcast(inv')                    # 当作一个新操作发给别人
6
push_to_redo(invert(inv'))         # 它的逆进 redo 栈，以便重做

总结#

总之做这个的话先有一个单一、清晰、可序列化的文档模型；在快照式和命令式之间根据规模和协同需求做出取舍；用事务和合并把撤销颗粒度对齐到用户的意图而不是数据结构；连同选区一起回退以保证上下文不丢；针对画布处理好连续交互的合并、把会话状态与文档状态分成两条通道，针对富文本处理好 IME 和原生 contenteditable 的接管； 如果有协同就从一开始按局部撤销和操作变换来设计，多数还是用 Yjs 这类成熟框架

反正具体情况具体来看。