HTML本身不支持撤销操作，真正实现撤销需依赖JavaScript维护历史栈或浏览器对contenteditable的隐式管理，但后者不稳定且易被JS干预破坏。
HTML 本身不支持撤销（undo）操作
HTML 是标记语言，不是运行时环境，它没有内置的 undo、redo 或历史栈机制。所谓“HTML 撤销依赖恢复操作”，实际是把责任错配给了 HTML —— 真正支撑撤销行为的是 JavaScript 配合 DOM 操作逻辑，或浏览器原生编辑控件（如 contenteditable 元素）的隐式能力。
常见误解场景：在 contenteditable="true" 的 <div> 里输入文字后按 Ctrl+Z 能撤回，但这并非 HTML 功能，而是浏览器对可编辑元素的默认编辑历史管理。一旦你用 JavaScript 直接修改 innerHTML 或调用 document.execCommand()（已废弃），这个隐式栈大概率被清空或失步。
contenteditable 元素的撤销行为不稳定，尤其在 JS 干预后
只要没手动干扰，contenteditable 元素对键盘输入、粘贴等用户直接操作保留较可靠的撤销链。但以下操作会破坏它：
- 用
element.innerHTML = newHtml替换内容 → 撤销栈重置，之前所有操作不可逆 - 调用已废弃的
document.execCommand('insertHTML')→ 在 Chrome/Firefox 中可能中断撤销序列 - 在输入过程中异步修改 DOM（如防抖格式化、实时语法高亮）→ 撤销点错位，Ctrl+Z 可能回退到错误状态
- 跨浏览器差异明显：Safari 对
contenteditable撤销支持最弱，常丢步或无法撤回格式变更
想可靠实现撤销，必须自己维护操作历史栈
绕过浏览器不可靠的隐式机制，唯一可控路径是手动记录状态快照或操作指令。关键取舍点：
立即学习“前端免费学习笔记（深入）”；
- 存完整 DOM 快照（
element.cloneNode(true)）→ 内存开销大，适合小文本、低频操作 - 存差异（diff）或命令对象（如
{ type: 'insert', pos: 12, text: 'abc' }）→ 轻量但需严格实现反向操作（undo函数） - 避免在
input或keydown事件中高频快照 → 触发卡顿，建议节流（如 300ms）或仅在beforeinput后存档 - 注意光标/选区恢复：撤销后必须用
getSelection()+Range手动还原焦点位置，否则用户会“丢失光标”
第三方库如 slate-js 或 prosemirror 并非银弹
它们封装了撤销逻辑，但默认行为仍依赖你正确使用其 API：
- 绕过编辑器接口直改 DOM（如
editor.domElement.innerHTML = ...）→ 撤销栈失效 - 自定义插件未调用
editor.undo()或未正确注册 command → 操作不入栈 -
prosemirror的tr.setMeta('preventDispatch', true)会跳过历史记录，调试时容易漏掉 - 服务端协同编辑（如 OT/CRDT）下，本地撤销可能和远端变更冲突，需额外做合并判断
真正难的不是“怎么加撤销”，而是“怎么让每次 DOM 变更都可追溯、可逆、可定位”。哪怕只做一个简单富文本栏，漏掉一次手动赋值或选区保存，用户按 Ctrl+Z 的那一刻就会发现——什么都没撤回去。
