前端表单撤销为什么回不去：beforeinput、composition 与 undo 栈边界

输入框里拦截了 beforeinput，校验逻辑看起来也能正常跑，但用户按下 Ctrl+Z 之后内容死活退不回去。这个问题一般不是撤销快捷键坏了，而是你的脚本在浏览器生成撤销记录之前就改了value，或是把中文输入法的拼词过程误判成了普通输入。

先把普通输入、撤销/重做和 IME 拼词状态分开校验：只在确实需要拦截的 beforeinput 分支里取消默认行为，其余的内容变更尽量交给浏览器维护原生的撤销栈。

先理清楚事件顺序：撤销不是普通的输入操作

在可编辑控件里，浏览器会先抛出一次输入意图，再决定要不要修改控件里的内容。普通字符插入常见的 inputType 是 insertText，删除操作可能是 deleteContentBackward，而 Ctrl+Z 触发的撤销通常会落到 historyUndo 里。如果监听器把所有事件都当成「有新字符输入」来处理，撤销动作就会被错误格式化或是直接拦截。

editor.addEventListener('beforeinput', (event) => {
  const undoable = event.inputType === 'historyUndo'
    || event.inputType === 'historyRedo';

  if (undoable) {
    // 让浏览器消费自己的 undo/redo 记录
    return;
  }

  if (event.inputType === 'insertText' && event.data === '#') {
    event.preventDefault();
  }
});

这里的重点不是把所有事件名挨个列全，而是先判断当前操作是不是历史记录回退/前进操作。调试的时候在控制台同时打印 inputType、data、isComposing 和当前的 value 值，往往比死盯着最终输出的字符串更快找到问题断点。

为什么脚本赋值之后 Ctrl+Z 就找不到上一笔记录了

很多表单会在 input 里做首尾空格裁剪、大小写转换或是掩码格式化，之后直接执行 textarea.value = normalized。这次赋值虽然改了屏幕上显示的内容，但并不属于用户刚才那次原生编辑的同一条历史记录。几次连续赋值之后，撤销动作可能只能回到浏览器还能识别的最后一个原生编辑节点。

更稳妥的方案是把「显示层格式化」和「提交前规范化」两个逻辑拆开。用户正在输入的过程里尽量保留原始文本，等失焦、提交或是用户主动触发格式化的时候再做转换。如果业务要求必须实时格式化，要同步记录 selectionStart、selectionEnd 和内容变换前后的长度，还要把撤销流程的校验当成单独的测试用例，不能只测最终输出的 value 对不对。

中文输入法的拼词阶段不能提前处理内容

中文拼音输入的时候，用户正在选的候选词还处在 composition 组合状态。这时候 input 可能会触发很多次，event.isComposing 也会标识当前内容还不是最终确认的文本。如果在拼词过程里就自动补全、替换标点或是同步远端草稿，很容易出现候选词被打断、按一次回退反而跳出半截拼音之类的异常。

editor.addEventListener('input', (event) => {
  if (event.isComposing) return;
  saveDraft(editor.value);
});

editor.addEventListener('compositionend', () => {
  saveDraft(editor.value);
});

这个处理方式不是说要完全忽略组合阶段的事件，而是把持久化的时间点推迟到拼词流程完全结束之后。测试的时候要切换至少一种中文输入法，同时覆盖「输入候选词后立刻按撤销」和「拼词确认结束后再按撤销」两条路径。

把修复验收拆成四个可复现的动作

1. 输入 abc，按一次 Ctrl+Z，确认内容回到空值；再按 Ctrl+Y，确认输入内容正常恢复。
2. 输入中文拼音完成选词，确认候选窗口不会被实时格式化逻辑打断。
3. 在文本中间位置插入字符之后执行撤销，确认光标位置和文本内容都正确回退。
4. 触发一次业务格式化逻辑之后再执行撤销，明确产品规则里要求的是回退到格式化前，还是只回退到用户上一次手动输入的状态。

如果前三项测试都通过、第四项大家对规则的争议很大，问题就不在事件监听器的逻辑里，而是产品侧没明确要不要把脚本自动变换的内容纳入历史记录。这时候别继续往代码里堆 setTimeout 或是自己手写快捷键监听，先把恢复模型定下来，再选择用原生 undo 能力、自定义快照栈或是编辑器组件提供的事务 API 实现。

常见问题

为什么监听 input 事件之后 historyUndo 还是会触发自动保存？

撤销操作执行完成之后，浏览器依然会触发一次 input 事件，用来通知内容已经发生变化。你可以在这个回调里保存最终结果，但不要在这里再次执行破坏 undo 栈的强制格式化逻辑。

用 preventDefault 能不能只拦截指定的字符？

可以在 beforeinput 事件里根据 inputType 和 data 属性做精确判断。拦截的范围越小越好，撤销和重做类的事件通常都要直接放行，不要做额外处理。

受控框架组件为什么更容易碰到这类撤销异常？

如果每次触发 input 事件都把规范化之后的值回写到 DOM 上，框架的渲染流程很可能覆盖浏览器刚生成的编辑状态。这类场景要尽量减少不必要的回写操作，同时把组合态、选区同步和 undo 流程的校验都纳入组件常规测试范围。

小结

表单撤销异常的排查顺序应该是：先辨认 inputType 的具体值，再确认当前是否处于 IME composition 组合状态，最后检查代码里有没有直接用脚本赋值修改 value 的逻辑。把默认的编辑流程交给浏览器处理，把业务规则限定在明确的拦截或是提交边界里，撤销、重做和中文输入的流程才不会互相抢占状态出问题。