用pop模拟栈实现撤销重做记录

本文深入解析了如何用 JavaScript 的 `pop` 和 `push` 操作正确模拟栈结构来实现健壮的撤销重做功能，强调仅靠 `pop` 无法构成完整栈行为，必须通过主栈与重做栈双栈协同、严格遵循尾部操作（避免低效的 `unshift`/`shift`）、在新动作前清空重做栈、合理判断边界条件及安全处理返回值等关键实践，同时提醒开发者警惕深拷贝开销、内存泄漏和逻辑时序陷阱——这些看似细微的设计选择，往往直接决定编辑类应用在高频操作下的流畅性与数据一致性。

pop 能不能直接当栈用？能，但得配 push

单靠 pop 无法构成完整栈行为——它只负责出栈，入栈必须用 push。撤销重做本质是「后进先出」的双端操作：每次新动作 push 到记录数组末尾，撤销就 pop 最后一个，重做则需另一个栈暂存被撤销的动作。

常见错误是只维护一个数组、只调用 pop，结果撤销后无法重做，或重做时把未撤销的动作也“恢复”了。

• 撤销 = 从主栈 pop → 推入重做栈
• 重做 = 从重做栈 pop → 推入主栈
• 主栈始终保存「当前可撤销的全部状态」，空数组表示无动作可撤

为什么不能直接用 pop 后再 unshift？性能掉太狠

unshift 在数组头部插入会触发全量元素位移，时间复杂度 O(n)，而 push/pop 是 O(1)。撤销重做频繁触发时（比如编辑器每敲一个字记一次），用 unshift 模拟栈顶会导致明显卡顿。

真实场景中，有人试图把新动作塞到数组开头、用 shift 撤销，逻辑看似对，但实测 1000 条记录后，连续撤销 100 次耗时可能比 push/pop 方案高 3–5 倍。

• 栈操作必须严格用尾部：入口 push，出口 pop
• 数组长度变化只影响 length 属性和最后一个索引，不挪动其他元素
• 浏览器对 push/pop 有底层优化，unshift/shift 没有

撤销重做的边界怎么判？看 length 就行

判断能否撤销，只看主栈 length > 0；判断能否重做，只看重做栈 length > 0。别用 undefined !== stack[stack.length - 1] 这类冗余检查——pop 对空数组返回 undefined，但你根本不会让它对空数组调用。

实操建议在调用前加守卫：

function undo() {
  if (mainStack.length === 0) return;
  const action = mainStack.pop();
  redoStack.push(action);
  applyReverse(action);
}

• 不要捕获 pop 返回值后再判断是否 undefined——那是补救，不是预防
• 清空重做栈的时机：每次新动作 push 前，重做栈必须清空（用户新建操作后，之前被撤销的就不可重做了）
• 状态快照不宜深拷贝整个应用状态，优先记录差异（如光标位置、修改字段名+旧值）

pop 返回值怎么用才安全？别直接当对象解构

pop 返回被删元素，但如果栈为空，它返回 undefined。直接解构会报错：const { type, payload } = mainStack.pop(); —— 空栈时解构 undefined 抛 TypeError。

正确做法是先确保有值，再解构，或用可选链：

const last = mainStack.pop();
if (last == null) return;
const { type, payload } = last;

• 避免写成 mainStack.pop()?.type：虽然不报错，但掩盖了本该被拦截的空栈逻辑分支
• 撤销函数应明确区分「无动作可撤」和「撤成功」两种返回，方便上层做 UI 禁用/启用
• 如果动作对象含函数或 DOM 引用，注意内存泄漏——撤销后记得手动清除引用

实际写的时候，最易被忽略的是「新动作 push 前清空重做栈」这一条。很多人测试时只点撤销再点重做，看起来没问题；但一旦中间插了一次新输入，重做栈没清，就会把老状态又刷回来，导致数据错乱。

到这里，我们也就讲完了《用pop模拟栈实现撤销重做记录》的内容了。个人认为，基础知识的学习和巩固，是为了更好的将其运用到项目中，欢迎关注golang学习网公众号，带你了解更多关于的知识点！