必须用双栈结构，因单列表存状态快照会导致内存浪费大、无法自动截断中间插入分支、语义模糊不可预测；双栈配合命令对象（含execute/undo方法）才能精准控制操作进出与逆向执行。
撤销操作历史管理的核心是把“每一步可逆动作”变成可执行、可反向执行的独立单元，并用栈来控制它们的进出顺序。单靠一个列表或变量快照很难兼顾准确性、内存效率和分支操作处理，而双栈结构配合命令封装，是最通用也最可控的落地方式。
为什么必须用两个栈，而不是一个列表存状态
只用一个列表记录状态快照，看似直观，但存在三个硬伤：
- 内存浪费大：每次操作都深拷贝整个对象，尤其在图形编辑或富文本场景下，开销随操作次数线性增长
- 无法处理“中间插入”：比如执行 A→B→C 后撤销到 B，再执行新操作 D，此时 C 及之后的历史必须丢弃，否则重做会错乱——单列表难以自动截断无效分支
- 语义模糊：列表里存的是“结果”而非“动作”，分不清哪次变化来自用户操作、哪次来自系统自动修正，导致 undo/redo 行为不可预测
命令对象怎么设计才真正可逆
关键不是保存数据，而是保存“做了什么”以及“怎么撤回来”。每个命令应包含两个方法：
-
execute()：正向执行逻辑，比如
canvas.addPoint(x, y)或text.insert("hello") -
undo()：严格对应的逆操作，比如
canvas.removeLastPoint()或text.deleteAt(pos, 5)
注意：pop 类操作必须在执行时捕获被移除的值，写进命令对象里，否则 undo 时无法还原。例如 pop() 日志记为 ('pop', 42)，undo 就是 push(42)。
双栈协同的典型流转规则
undoStack 存已执行命令，redoStack 存刚被撤销的命令，它们的更新不是对称的：
- 执行新命令 → push 到 undoStack，同时清空 redoStack
- 点击 Undo → 从 undoStack pop 命令，调用其 undo()，再 push 到 redoStack
- 点击 Redo → 从 redoStack pop 命令，调用其 execute()，再 push 到 undoStack
- 任意新操作发生后，redoStack 必须清空，避免“跳步重做”破坏线性历史
实际编码中容易忽略的关键细节
很多实现跑起来能 undo，但一加 redo 就出错，问题常出在边界和状态同步上：
- 空栈调用 pop() 必须有 guard，比如
if (undoStack.length) { ... } - UI 按钮状态要实时响应栈长度：
undoBtn.disabled = undoStack.length === 0 - 命令对象内不应持有对外部可变对象的直接引用（如
this.canvas），而应通过闭包捕获必要参数，避免状态漂移 - 批量操作（如连续输入 10 个字符）可合并为一条命令，减少栈深度，提升响应速度
