Excalidraw撤销重做层级：最多支持多少步？

Excalidraw撤销重做层级：最多支持多少步？

在数字白板工具日益普及的今天，无论是远程团队协作画流程图，还是开发者随手勾勒系统架构，Excalidraw 都成了许多人的首选。它那手绘风格的界面不仅让人放松，更重要的是——够快、够轻、够聪明。尤其是当你画错了一根线、删掉了一个关键模块时，本能地按下Ctrl+Z，那种“还能救”的安心感，几乎成了现代编辑器的标配。

但你有没有想过：这个“撤销”到底能回退多远？我一口气改了150步，还能不能全撤回来？Excalidraw 到底记了多少步历史？

这个问题看似简单，背后却牵扯出前端状态管理的核心设计逻辑：如何在用户体验和内存开销之间找到平衡点。

我们先说结论：Excalidraw 默认最多支持 100 步撤销操作。也就是说，无论你是添加形状、移动元素，还是修改文本内容，系统只会保留最近的 100 个可逆操作节点。超过这个数，最早的操作就会被自动丢弃。

这并不是拍脑袋定的数字，而是经过权衡后的工程选择。

撤销功能不只是“按一下 Ctrl+Z”

要理解为什么是100步，得先搞清楚撤销重做到底是怎么工作的。

大多数图形编辑器（包括 Figma、Sketch、甚至 Photoshop）都采用一种叫命令模式（Command Pattern）的设计思想。简单来说，就是把每一次用户操作封装成一个“指令包”，比如：

{ type: "update", elementId: "rect-123", property: "x", from: 100, to: 150 }

每当发生变更，这个指令就被推入一个叫做Undo Stack（撤销栈）的数组里。而当你按下Ctrl+Z，系统就从栈顶弹出最新操作，执行它的“反向动作”，比如把x从 150 改回 100，并把这个操作转移到另一个叫Redo Stack（重做栈）的地方。

这样一来，你不仅能一步步往回退，还能再一步步往前走——就像时间机器一样双向穿梭。

但如果每个鼠标移动都记录一次呢？拖动一个矩形滑过屏幕，可能产生几十甚至上百次位置更新。如果全都存下来，别说100步，十几秒就能把历史栈撑爆。

所以 Excalidraw 做了个聪明的处理：操作合并（coalescing）。

比如你在连续几百毫秒内多次移动同一个元素，系统会把这些零散的变化合并成一条“最终移动”记录。这样既保留了可撤销性，又避免了历史记录过度膨胀。

这也解释了为什么有时候你觉得“好像少撤了几步”——不是没生效，而是系统帮你做了精简。

技术实现：双栈结构 + 容量限制

翻一翻 Excalidraw 的 GitHub 仓库，你会发现核心逻辑藏在一个叫history.ts的文件里。其中有个常量定义非常关键：

const MAX_STACK_SIZE = 100;

没错，这就是那个决定命运的数字。

下面是一个简化版的实现模型，基本还原了其工作机制：

interface HistoryEntry { type: "add" | "delete" | "update"; elementsBefore: ExcalidrawElement[]; elementsAfter: ExcalidrawElement[]; } class HistoryManager { private undoStack: HistoryEntry[] = []; private redoStack: HistoryEntry[] = []; private readonly maxSteps = 100; pushEntry(entry: HistoryEntry) { if (this.undoStack.length >= this.maxSteps) { this.undoStack.shift(); // 超限时移除最老的一条 } this.undoStack.push(entry); this.redoStack = []; // 新操作打断重做链 } undo(): ExcalidrawElement[] | null { if (this.undoStack.length === 0) return null; const entry = this.undoStack.pop()!; this.redoStack.push(entry); return [...entry.elementsBefore]; } redo(): ExcalidrawElement[] | null { if (this.redoStack.length === 0) return null; const entry = this.redoStack.pop()!; this.undoStack.push(entry); return [...entry.elementsAfter]; } canUndo() { return this.undoStack.length > 0; } canRedo() { return this.redoStack.length > 0; } }

几个关键点值得注意：

• 使用shift()而非无限 push，确保栈不会无节制增长；
• 每次新操作都会清空redoStack，符合“分支历史不可复原”的通用行为；
• 只保存变化前后状态的差异（diff），而不是整个画布快照，大幅节省内存；
• 所有数据驻留在内存中，页面刷新即丢失。

这种设计在浏览器环境下尤为合理：轻量、响应快、不依赖复杂存储机制。

实际使用中的体验与边界

假设你正在画一张复杂的微服务架构图，花了半小时加了二十多个节点，调了布局，改了颜色。然后你不小心点了“全部删除”……这时候你会怎么办？

当然是狂按Ctrl+Z！

只要总操作步数没超过100步，你大概率能救回来。但如果在这之前你还做过大量其他改动（比如反复调整连线、增删标签等），早期的一些操作可能已经被挤出了历史栈——这就意味着，哪怕你只删了一个东西，也可能因为历史深度不足而无法完全恢复。

更现实的问题是：协作场景下，撤销只能作用于自己的操作。

A 用户删了个框，B 用户没法通过“撤销”来把它变回来。因为 A 的操作走的是 WebSocket 同步到服务端，再广播给所有人，这类远程变更并不会进入本地用户的 undo 栈。这是为了防止混乱，但也带来了局限。

此外，目前的历史记录完全是临时性的。关闭浏览器标签？历史清零。没有插件或扩展支持跨会话恢复撤销状态，除非你自己导出.excalidraw文件作为备份。

开发者视角：能不能改得更多？

当然可以——只要你愿意承担代价。

如果你 fork 了项目，完全可以把MAX_STACK_SIZE改成 200、500 甚至 1000。但要注意：

• 每个历史节点平均可能占用几 KB 到几十 KB 内存（取决于画布复杂度）；
• 100 步 × 每步 50KB ≈ 5MB，听起来不多，但在低端设备上仍会影响性能；
• 过长的栈会导致序列化、比较、合并等操作变慢，拖累整体响应速度；
• 移动端尤其敏感，内存资源有限。

因此，100 是一个经过验证的“甜点值”：足够应对绝大多数创作场景，又不至于造成明显负担。

不过社区也在探索改进方向，例如：
- 引入压缩差分算法（如 JSON-Patch），进一步减小单条记录体积；
- 利用IndexedDB实现部分历史持久化，支持跨会话恢复；
- 提供用户可配置选项，允许高级用户自行设定最大步数。

这些都不是做不到，只是要在通用性和专业性之间做取舍。

如何更好地利用这一功能？

对于普通用户，这里有几点实用建议：

✅掌握快捷键
-Ctrl+Z：撤销
-Ctrl+Shift+Z或Ctrl+Y：重做
熟记这两个组合，能让你的编辑效率翻倍。

✅定期手动保存
别完全依赖撤销。重要图表务必点击“导出”按钮，生成.excalidraw文件本地存档。这是真正的“终极保险”。

✅避免高频暴力操作
短时间内疯狂增删元素，可能会触发防抖机制，导致中间状态被跳过。建议阶段性停顿，让系统有机会打点记录。

✅理解“合并”的存在
连续拖动、缩放、旋转等操作通常只记为一步。这不是 bug，是优化。如果你需要精细控制每一步，可以尝试配合“锁定”或“分步提交”策略。

更深层的设计哲学

Excalidraw 的撤销机制其实反映了一种典型的前端工程思维：以有限资源模拟无限体验。

它不追求“永远可撤销”，而是提供一段合理的安全缓冲区。就像汽车的安全气囊——不需要每次碰撞都完美复原，只需要在关键时刻起作用就够了。

而且它的设计极具延展性。基于 Zustand 状态管理库构建的状态流体系，使得历史模块可以轻松接入插件系统。未来完全可能出现这样的功能：

“启用持久化历史插件后，您在过去三天内的所有操作均可撤销。”

这并非天方夜谭，已有实验性项目在尝试类似方案。

结语

回到最初的问题：Excalidraw 最多支持多少步撤销？

答案很明确：默认 100 步。

但这 100 步的背后，是一整套关于性能、体验与实用性的精密计算。它不是一个随意设定的上限，而是一种对真实使用场景的深刻理解。

对于用户而言，了解这个边界有助于建立合理的操作预期；对于开发者来说，这套机制则是一个绝佳的学习范本——如何用简洁的双栈结构，支撑起流畅自然的交互体验。

也许未来的某一天，我们会看到支持千级撤销步数、甚至云端同步操作历史的智能白板。但在当下，Excalidraw 用最朴实的方式告诉我们：好的工具，不在于功能有多多，而在于每一项功能都恰到好处。