await 本身不能实现撤销重做，关键在于命令对象+操作栈+显式状态管理；每个command封装execute/undo/redo方法并支持await异步操作，通过维护undostack和redostack实现可逆控制。
await 本身不能直接实现撤销重做，它只是暂停异步函数执行、等待 Promise 解析，并不记录操作历史或管理状态变迁。所谓“完美复刻同步命令模式下的撤销重做”，关键不在 await，而在于**命令对象 + 操作栈 + 显式状态管理**的设计模式。await 只是让这个模式在异步场景下写起来像同步一样清晰。
核心思路：把每一步封装为可逆的 Command 对象
同步命令模式中，每个操作（如“插入文本”“删除节点”）被封装成包含 execute()、undo()、redo() 的对象。异步场景下，这些方法可以返回 Promise，而 await 让调用方能自然等待完成：
- 定义 Command 类，每个实例携带必要上下文（如编辑器引用、原始值、目标位置）
-
execute()执行主逻辑（可能含 await API 调用），成功后将自身推入 undo 栈 -
undo()恢复前一状态（也支持 await 异步清理，如回滚服务端变更） - 维护两个栈：
undoStack（已执行、可撤）、redoStack（已撤销、可重）
用 await 串起多步，但撤销逻辑独立于执行流程
你写的是线性代码，但撤销能力来自 Command 的元信息，不是 await 的副作用：
- ✅ 正确写法：
await cmd1.execute();<br>await cmd2.execute();<br>await cmd3.execute();<br>// 此时 undoStack = [cmd1, cmd2, cmd3]
- ❌ 错误期待：以为
await cmd1(); await cmd2();自动产生可逆链条 —— 实际上没有命令对象和栈，就什么也撤不了
异步命令的典型实现片段
例如一个支持远程保存的文本编辑命令：
-
execute()：更新本地模型 → await saveToServer() → push 到 undoStack -
undo()：恢复本地快照 → await revertOnServer() → pop 并 push 到 redoStack - 用户点“撤销”时，不重新 await 原执行过程，而是直接调用栈顶 command 的
undo()
注意事项：避免常见陷阱
- 不可将 await 用于非 Promise 值（如普通函数），否则会立即 resolve，失去挂起效果
- 撤销重做必须是幂等的：多次 undo/redo 不应导致状态漂移
- 若某步 execute 失败，需在 catch 中清理已执行的前置命令（即“补偿事务”），不能只靠栈回退
- UI 状态（如按钮禁用）要与 undoStack/redoStack 长度联动，而非依赖 await 的执行顺序视觉反馈
