HTML撤销依赖恢复操作？避坑指南

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的那一刻，他会发现——什么都没撤回去。这才是最要命的。