history.pushState不能当“撤销”用，因其仅管理URL导航状态，不保存光标、选区、输入法等DOM状态，且state对象无操作级数据，无法自动还原编辑行为。
不需要，HTML 历史记录（window.history）本身不提供操作回溯能力，也不能替代操作级撤销/重做；二者目标不同、数据粒度不同、实现机制也完全隔离。
为什么 history.pushState 不能当“撤销”用
浏览器的 history API 管理的是 URL 导航状态，不是 DOM 或表单操作。调用 history.pushState 后，即使你保存了完整 HTML 快照，点击后退时也不会自动还原光标位置、选区、contenteditable 的富文本格式、input 的输入法状态——这些全得你自己恢复。
- 常见错误现象：
popstate触发了，但表单值没变、编辑器光标卡在开头、富文本加粗失效 - 根本原因：state 对象里只存了 URL 和简单元数据（如
{ versionId: 'v123' }），没存 DOM 树、selection、input 光标偏移量 - 性能影响：若每次 push 都深拷贝整个
document.body，内存增长快，尤其含大量图片或 canvas 的页面
操作回溯必须自己维护独立状态栈
真正的“撤消上一步”，比如删了一段文字、拖动了一个组件、切换了某个开关，得靠 JavaScript 主动捕获并序列化操作行为，而不是依赖 URL 变化。
- 表单类操作：监听
input、change、blur，保存input.value、textarea.value、checkbox.checked等字段快照 - 富文本编辑：禁用原生
Ctrl+Z（event.preventDefault()），用getSelection()+range.cloneContents()记录选区和内容，避免用innerHTML快照（会丢格式） - DOM 结构变更：对插入/删除节点的操作，记录
node.outerHTML+ 父节点id+ 插入位置索引，而不是整个 document 快照 - 步数限制：栈长度建议 ≤ 50，防止内存泄漏；旧条目可用
JSON.stringify压缩后存sessionStorage
history 和操作栈怎么协同才不翻车
两者可以共存，但必须明确边界：URL 变化负责「导航层级」，操作栈负责「编辑动作」。比如一个可视化编辑器，左侧菜单切换是 history 驱动，右侧画布拖拽是操作栈驱动。
立即学习“前端免费学习笔记（深入）”；
- 不要在
popstate里直接调用undo()——这会让用户点浏览器后退时意外撤销内容，违背直觉 - 正确做法：URL 变更只触发视图切换（如加载新模板），再根据新模板的初始状态重置操作栈（
stack = [initialState]） - 刷新问题：页面刷新后
history.state为空，但操作栈还在sessionStorage里；需在DOMContentLoaded时检查是否要从 storage 恢复栈，并同步到当前视图 - 兼容性注意：
history.replaceState在 iOS Safari 14.5 以下可能不触发popstate，务必加降级 fallback（如监听hashchange）
最容易被忽略的一点：操作回溯的“一步”，必须对应用户可感知的最小语义单元。比如一次粘贴 50 行代码，应该算作“一步”，而不是拆成 50 次 input 事件。否则栈爆炸，且用户根本无法理解撤销到底撤了什么。
