答案是采用命令模式管理编辑操作，通过封装执行与撤销方法、维护撤销重做栈、合并连续输入及可选快照优化，实现高效富文本编辑器状态控制。
实现一个支持撤销、重做和历史记录的富文本编辑器核心，关键在于状态管理与操作抽象。不能依赖 DOM 快照，因为性能差且不可控。正确做法是将用户操作建模为可逆的动作对象，并通过命令模式统一管理。
1. 使用命令模式封装编辑操作
每个用户编辑行为（如插入文字、删除、格式化）都应封装为一个命令对象，包含执行和撤销方法。
• 每个命令实现 execute() 和 undo() 方法• 命令需携带足够的上下文信息，如光标位置、选中内容、格式类型等
• 所有用户触发的编辑必须通过命令调度器执行，不能直接修改编辑器状态
• 示例：加粗命令在执行时给选中文本添加 <strong> 标签，撤销时移除标签并恢复原始结构
2. 构建撤销/重做栈
维护两个栈：一个存放已执行的操作（undoStack），另一个存放被撤销的操作（redoStack）。
• 用户操作后，命令推入 undoStack，清空 redoStack• 撤销时，从 undoStack 弹出命令执行 undo()，并推入 redoStack
• 重做时，从 redoStack 弹出命令执行 execute()，再推回 undoStack
• 设置栈深度限制（如 50 步），避免内存泄漏
3. 合并连续输入提升体验
频繁输入（如打字）若每键生成一条命令，会导致撤销粒度太细。需合并短时间内的连续插入。
• 记录上一个命令的时间和类型
• 若当前为插入字符且距上次操作小于 1 秒，合并到前一个插入命令中
• 删除操作或格式变化不参与合并
• 合并逻辑在命令入栈前判断处理
4. 快照与差异检测（可选优化）
对于复杂场景，可在关键节点保存轻量级状态快照（如 HTML 结构指纹或 AST 哈希）。
• 用于检测是否发生实质性变更，避免无意义的历史记录• 可辅助实现“自动保存”或“版本对比”功能
• 不替代命令系统，仅作补充
基本上就这些。核心是把“动作”当成数据来管理，而不是事后去抓 DOM 变化。这样既能精准控制撤销行为，又能保证性能和一致性。
