命令模式：把操作封装成可撤销、可序列化的对象

1. 命令模式不是“发号施令”，而是把“动作”变成可存、可传、可撤的“对象”

很多人第一次听到“命令模式”，脑子里立刻浮现出一个穿军装的人站在高台上喊“立正！稍息！向右看齐！”，以为这是在讲怎么设计一套权限系统或者流程审批链。其实完全跑偏了——命令模式的核心，从来不是“谁有权下命令”，而是如何把一个操作（比如点击保存、撤销上一步、切换主题）从执行逻辑中抽离出来，封装成一个独立、可复用、可延迟、可排队、甚至可记录的对象。

我最早在做一个轻量级文本编辑器Demo时踩过这个坑：所有按钮点击事件里直接写editor.save()、editor.undo()、editor.setFontSize(14)……代码越写越臃肿，想加个“批量执行历史命令”功能？得翻遍所有事件监听器；想支持Ctrl+Z连续撤销三次？得手动维护一个栈，还得同步更新UI状态；更别说后期要加“宏录制”或“远程协作指令同步”——当时改得头皮发麻，最后推倒重来，才真正吃透命令模式的价值。

它解决的不是“权限控制”问题，而是行为与调用者解耦、行为可序列化、行为生命周期可控这三类高频痛点。关键词“命令模式”背后，实际对应着四个关键能力：封装性（把do()和undo()打包进一个类）、可传递性（能作为参数传给菜单、快捷键、日志模块）、可存储性（能放进队列、栈、数据库）、可组合性（多个命令可包装成一个复合命令）。这些能力，在GUI应用、游戏开发、自动化脚本、工作流引擎甚至IoT设备控制中，都是刚需。

适合谁读？如果你正在写一个需要支持撤销/重做、宏操作、任务队列、异步执行、操作审计或用户自定义快捷键的系统，哪怕只是个带历史记录的计算器，命令模式都不是“可选项”，而是“避不开的底层结构”。它不炫技，但一旦用对，后续所有扩展都像搭积木一样自然。下面我们就从真实项目视角，一层层拆开它的骨架、血肉和神经末梢。

2. 整体设计思路：为什么非得把“函数调用”变成“对象实例”？

2.1 传统做法的硬伤：散落的函数调用 vs 集中的命令对象

先看一个典型反例。假设我们开发一个简易绘图工具，支持画线、画矩形、填充颜色三种操作：

// ❌ 反模式：所有操作逻辑散落在事件处理器中 document.getElementById('btn-line').addEventListener('click', () => { canvas.drawLine(startX, startY, endX, endY); history.push({ type: 'line', data: { startX, startY, endX, endY } }); updateUI(); }); document.getElementById('btn-rect').addEventListener('click', () => { canvas.drawRectangle(x, y, width, height); history.push({ type: 'rect', data: { x, y, width, height } }); updateUI(); }); document.getElementById('btn-fill').addEventListener('click', () => { canvas.fillColor(color); history.push({ type: 'fill', data: { color } }); updateUI(); });

问题立刻暴露：

• 重复代码多：每次操作后都要history.push()和updateUI()，违反DRY原则；
• 撤销难实现：history里存的是原始数据，但undo()需要知道如何“反向操作”——画线的undo是删线，填充的undo是恢复原色，逻辑完全不同，无法统一处理；
• 扩展成本高：新增“旋转画布”功能？得再复制一遍事件绑定+历史记录+UI更新三段逻辑；
• 测试困难：无法单独测试“画线”这个行为本身，只能测整个点击事件流。

而命令模式的解法，是把每个操作抽象为一个具备完整生命周期的对象：

// ✅ 命令模式核心：每个操作是一个类，封装执行、撤销、描述 class DrawLineCommand { constructor(canvas, startX, startY, endX, endY) { this.canvas = canvas; this.startX = startX; this.startY = startY; this.endX = endX; this.endY = endY; this.lineId = null; // 用于撤销时删除 } execute() { this.lineId = this.canvas.drawLine(this.startX, this.startY, this.endX, this.endY); } undo() { if (this.lineId) this.canvas.removeShape(this.lineId); } getDescription() { return `画线: (${this.startX},${this.startY}) → (${this.endX},${this.endY})`; } }

看到区别了吗？不是“调用函数”，而是“创建对象”——new DrawLineCommand(canvas, 10, 20, 100, 200)。这个对象里既存了执行所需的所有上下文（canvas引用、坐标），也定义了如何执行（execute）和如何回滚（undo），甚至还能自我描述（getDescription）。它不再依赖某个特定的UI按钮，可以被菜单调用、被快捷键触发、被脚本批量生成、被网络消息反序列化重建。

2.2 模式选型背后的三个关键权衡

为什么不用更简单的策略模式（Strategy）或观察者模式（Observer）？这里必须说清楚三个关键决策点：

第一，为什么不是策略模式？
策略模式解决的是“算法替换”问题（比如排序用快排还是归并），关注的是同一目标的不同实现方式。而命令模式解决的是“行为封装与调度”问题，关注的是不同目标的统一管理接口。画线和填充是完全不同的行为，不存在“互换算法”的需求，强行套策略模式只会让execute()方法里堆满if-else判断类型，违背开闭原则。

第二，为什么不是观察者模式？
观察者模式解决的是“状态变更通知”，比如Canvas修改后通知所有监听器刷新UI。但它不解决“如何定义修改本身”——你通知的是“画布变了”，但没定义“这次变化具体是什么操作”。命令模式恰恰补上了这一环：它先定义清楚“这次变化是画了一条线”，再把这个定义好的变化对象，交给观察者去通知、交给历史栈去存储、交给撤销管理器去执行undo。

第三，为什么必须是对象，不能是函数？
JavaScript里确实可以用闭包模拟命令对象，比如() => canvas.drawLine(...)。但函数无法天然携带undo()方法和getDescription()方法，也无法在运行时动态检查其类型（cmd instanceof DrawLineCommand比typeof cmd === 'function'有用得多）。更重要的是，对象可以被序列化为JSON（只要属性是纯数据），而函数无法序列化。当你要把用户操作存到localStorage、同步到协作服务器、或生成操作日志报表时，对象是唯一可行载体。

提示：命令对象不是越“重”越好。我见过有人把整个Canvas实例塞进命令对象，导致内存泄漏。正确做法是只存必要参数（坐标、颜色值等原始数据），执行时通过依赖注入获取Canvas等服务对象。这点在3.2节会详细展开。

2.3 真实项目中的架构定位：它处在哪一层？

在分层架构中，命令模式通常位于应用层（Application Layer）与领域层（Domain Layer）之间，扮演“用例编排者”的角色。它不处理业务规则（那是领域层的事），也不处理UI渲染（那是表现层的事），而是把用户意图（点击按钮）翻译成领域对象能理解的一系列原子操作。

以电商下单为例：

• 表现层：用户点击“提交订单”按钮；
• 应用层：创建CreateOrderCommand对象，包含用户ID、商品列表、收货地址等参数；
• 领域层：OrderService.execute(command)解析命令，调用InventoryService.reserveStock()、PaymentService.charge()等；
• 命令对象本身：只负责携带参数、定义执行/撤销逻辑（如库存预留失败时自动释放）、提供日志描述。

这种分层让系统具备极强的可测试性——你可以完全脱离UI，直接实例化CreateOrderCommand，注入Mock服务，验证整个下单流程是否按预期执行和回滚。这也是为什么大型框架（如Redux的Action、CQRS中的Command）都默认采用命令模式思想：它让“做什么”和“怎么做”彻底分离。

3. 核心细节解析：命令对象的四大要素与七种变体

3.1 一个合格的命令对象必须包含的四个基本要素

命令模式的UML类图看似简单，但实际落地时，很多团队只实现了execute()，却忽略了其他三个要素，导致后续扩展举步维艰。根据我参与过的6个中大型项目经验，一个生产环境可用的命令对象，必须明确包含以下四部分：

1. 执行上下文（Receiver）
即命令最终作用的目标对象。它必须是稳定、无状态、可复用的服务实例。例如绘图工具中的Canvas、文档编辑器中的Document、支付系统中的PaymentGateway。关键原则：命令对象持有Receiver的引用，但不创建它。Receiver应由上层（如CommandInvoker或DI容器）注入，避免命令对象与具体实现强耦合。

2. 执行参数（Parameters）
即命令执行所需的全部输入数据。必须是不可变（Immutable）的原始值或简单POJO。禁止在参数中传入复杂对象（如整个User实体），否则序列化时会拖垮性能。正确做法是只传ID（userId: 123），执行时再通过Repository查询完整数据。

3. 执行逻辑（Execute Method）
这是命令的“正向行为”。必须是幂等的（Idempotent）——多次调用execute()不应产生副作用。例如DrawLineCommand.execute()如果每次都新建一条线，就不是幂等的；正确实现应先检查是否已执行，或确保lineId唯一。幂等性是支持重试、断点续传、分布式事务的基础。

4. 撤销逻辑（Undo Method）
这是命令的“反向行为”。必须与execute()严格对称。如果execute()创建了资源，undo()必须销毁；如果execute()修改了状态，undo()必须恢复原值。最危险的误区是认为“撤销就是重新执行一次反向命令”——比如FillCommand.execute()设颜色为红色，undo()设回白色，但如果用户中间手动改过颜色，白色就不是原值。正确做法是在execute()中主动保存原状态（this.originalColor = canvas.getColor()），undo()直接恢复。

注意：不是所有命令都需要undo()。后台任务（如发送邮件、生成报表）通常不可逆。此时undo()可抛出UnsupportedOperationError，或设计为NoOpCommand（空操作命令），避免调用方做冗余判断。

3.2 七种常见变体及其适用场景

命令模式绝非“一个模板走天下”。根据项目复杂度，我会灵活选用以下七种变体，每种都有明确的适用边界：

变体1：基础命令（Basic Command）
最简形态，仅含execute()和undo()。适用于功能单一、参数固定的场景，如“切换夜间模式”、“播放/暂停音乐”。优点是代码量最少，缺点是难以组合。

变体2：参数化命令（Parameterized Command）
构造函数接收配置对象，execute()根据参数分支执行。例如TextFormatCommand接受{ bold: true, italic: false, size: 14 }。适用于同一类操作有多种变体，但需注意参数过多时应拆分为多个子命令。

变体3：宏命令（Macro Command）
内部持有一个命令数组，execute()依次执行所有子命令，undo()逆序执行所有子命令的undo()。这是实现“批量操作”和“事务性操作”的标准解法。例如“导入Excel”命令，可包装为[ValidateCommand, ParseCommand, SaveCommand]。关键技巧：宏命令自身也应实现getDescription()，返回子命令描述的拼接，方便日志追踪。

变体4：延迟命令（Deferred Command）
增加schedule(time)方法，将execute()推迟到指定时间执行。适用于定时任务、防抖操作（如搜索框输入300ms无新输入再触发搜索）。实现时需用setTimeout或requestIdleCallback，并提供cancel()方法中断计划。

变体5：异步命令（Async Command）
execute()返回Promise，undo()也返回Promise。适用于涉及网络请求、文件IO的操作。重点在于错误处理：execute()失败时，应自动触发undo()（如果已部分执行），或提供onError()钩子。我习惯在基类中统一实现tryExecute()方法，封装try-catch逻辑。

变体6：可序列化命令（Serializable Command）
所有属性必须是JSON可序列化的（字符串、数字、布尔、数组、纯对象）。增加toJSON()和fromJSON(json)静态方法。这是实现操作持久化、跨设备同步、协作编辑的基石。例如Figma的协作协议，就是将用户操作序列化为JSON命令流，通过WebSocket广播给所有客户端。

变体7：带元数据的命令（Metadata Command）
额外添加timestamp（执行时间）、userId（操作人）、sessionId（会话ID）、source（来源：鼠标/键盘/脚本）等字段。这些字段不参与业务逻辑，但对审计、监控、A/B测试至关重要。建议用装饰器模式动态添加，避免污染核心命令逻辑。

实操心得：不要一上来就设计“全能命令基类”。我推荐渐进式演进：先用基础命令跑通MVP，当出现“需要撤销”时加undo()，当出现“需要批量”时引入宏命令，当出现“需要同步”时加序列化支持。过早设计复杂基类，90%的功能永远用不上，反而增加维护成本。

3.3 命令的生命周期管理：Invoker、History、Queue三者如何协同？

命令对象本身是“死”的，需要“活”的管理者赋予它生命。这三个核心组件，构成了命令模式的运行时骨架：

Invoker（调用者）
它是命令的“启动开关”，负责接收用户输入（点击、快捷键、API调用），创建命令对象，并调用其execute()。关键设计原则：Invoker不关心命令具体做什么，只负责调度。例如菜单栏的MenuInvoker，只需知道command.execute()，无需知道DrawLineCommand内部如何画线。

class MenuInvoker { constructor() { this.history = new HistoryStack(); this.queue = new CommandQueue(); } // 统一入口：任何操作都走这里 executeCommand(command) { command.execute(); this.history.push(command); // 记录到历史栈 this.queue.enqueue(command); // 加入执行队列（用于日志、监控） } }

History（历史栈）
专门管理可撤销操作的LIFO（后进先出）栈。核心方法：push(command)、pop()（获取最近命令）、undo()（执行栈顶命令的undo()并弹出）、redo()（将undo()过的命令重新execute()并压回栈）。难点在于redo()的实现——需要额外维护一个“已撤销栈”。我的经验是：undo()时把命令从history移到redoStack，redo()时再移回来并执行。

Queue（执行队列）
用于异步、批量、优先级调度。例如后台导出大文件时，不能阻塞UI，应放入ExportQueue，由Worker线程消费。队列可支持优先级（紧急操作插队）、限流（每秒最多执行3个命令）、重试（网络失败时自动重试3次）。我常用Redis List实现分布式命令队列，保证多实例间操作顺序一致。

三者关系图（文字描述）：
用户操作 → Invoker创建命令 → 同时分发给History（存档）、Queue（异步执行）、Logger（审计）→ History响应撤销请求 → Queue响应批量执行请求。它们像交响乐团的不同声部，各自专注，又通过命令对象这个“乐谱”完美协同。

4. 实操过程：从零实现一个支持撤销/重做的富文本编辑器命令系统

4.1 环境准备与依赖选型

我们以一个基于ContentEditable的富文本编辑器为载体，实现完整的命令模式系统。技术栈选择遵循“够用、稳定、易调试”原则：

• 核心框架：原生JavaScript（不依赖React/Vue），避免框架生命周期干扰，直面DOM操作本质；
• DOM操作库：rangy（处理光标位置、选区操作，比原生Selection API更健壮）；
• 状态管理：自研轻量级HistoryStack（不引入Redux等重型方案）；
• 构建工具：Vite（热更新快，打包体积小）；
• 测试：Jest（单元测试命令逻辑）、Cypress（E2E测试撤销/重做流程）。

为什么不用现成的document.execCommand()？因为它是浏览器原生API，无法自定义undo()逻辑，且已被Chrome标记为废弃。我们必须自己实现所有格式化命令，才能获得完全控制权。

项目结构规划：

/src /commands # 所有命令类 BaseCommand.js # 抽象基类，定义execute/undo/getDescription BoldCommand.js # 加粗命令 InsertImageCommand.js # 插入图片命令 MacroCommand.js # 宏命令基类 /history # 历史管理 HistoryStack.js # 核心历史栈实现 /invokers # 调用者 ToolbarInvoker.js # 工具栏按钮调用者 KeyboardInvoker.js # 快捷键调用者 /utils # 工具函数 domUtils.js # DOM操作辅助函数 serialization.js # 命令序列化工具

注意：所有命令类必须继承BaseCommand，强制实现execute()和undo()，避免遗漏关键方法。TypeScript用户可定义interface Command { execute(): void; undo(): void; getDescription(): string; }，但即使JS项目，也应在基类中用throw new Error('Not implemented')占位。

4.2 基础命令基类与BoldCommand实战

先定义BaseCommand，它不处理具体业务，只提供通用能力：

// src/commands/BaseCommand.js export class BaseCommand { constructor(receiver, ...params) { this.receiver = receiver; // 接收者，如Editor实例 this.params = params; // 执行参数，保持不可变 this.timestamp = Date.now(); this.id = Math.random().toString(36).substr(2, 9); // 唯一ID，用于日志追踪 } // 子类必须实现 execute() { throw new Error('execute() must be implemented by subclass'); } undo() { throw new Error('undo() must be implemented by subclass'); } getDescription() { return `${this.constructor.name} at ${new Date(this.timestamp).toLocaleTimeString()}`; } // 通用序列化方法：只序列化params和constructor.name toJSON() { return { type: this.constructor.name, params: this.params, timestamp: this.timestamp, id: this.id }; } // 静态工厂方法：根据JSON重建命令 static fromJSON(json, receiver) { const CommandClass = window[json.type]; // 简单实现，生产环境用Map映射 if (!CommandClass) throw new Error(`Unknown command type: ${json.type}`); return new CommandClass(receiver, ...json.params); } }

现在实现第一个具体命令：BoldCommand。它需要处理三种场景：选中文本加粗、光标处插入加粗标签、全选时加粗所有内容。

// src/commands/BoldCommand.js import { BaseCommand } from './BaseCommand.js'; import { getSelectionRange, wrapSelection } from '../utils/domUtils.js'; export class BoldCommand extends BaseCommand { constructor(editor) { super(editor); // 关键：执行前捕获当前选区状态，用于undo this.selectionState = getSelectionRange(); this.originalHTML = null; // 存储原始HTML，用于还原 } execute() { const range = getSelectionRange(); if (!range || range.collapsed) { // 光标处插入<b></b>，并将光标置于中间 wrapSelection('<b>|</b>'); return; } // 选区存在：包裹选区内容 const wrapper = document.createElement('b'); const fragment = range.extractContents(); wrapper.appendChild(fragment); range.insertNode(wrapper); // 保存原始HTML用于undo（注意：只存outerHTML，避免序列化整个DOM树） this.originalHTML = wrapper.outerHTML; } undo() { if (!this.originalHTML) return; const range = getSelectionRange(); if (!range) return; // 创建临时div解析originalHTML const temp = document.createElement('div'); temp.innerHTML = this.originalHTML; // 替换当前节点为原始HTML const wrapper = range.commonAncestorContainer; if (wrapper && wrapper.nodeType === Node.ELEMENT_NODE) { wrapper.outerHTML = this.originalHTML; } } getDescription() { return `加粗文本: ${this.selectionState ? '选区操作' : '光标插入'}`; } }

这里有几个关键细节：

• getSelectionRange()封装了跨浏览器的Selection API调用，返回标准化的Range对象；
• wrapSelection()处理光标插入的边界情况（如<b>|</b>中的|代表光标位置）；
• undo()不依赖DOM状态，而是用originalHTML精确还原，确保幂等性；
• getDescription()返回可读字符串，后续可直接显示在“撤销历史”面板中。

4.3 历史栈（HistoryStack）的健壮实现

历史栈是撤销/重做的心脏，必须处理各种边界情况。以下是经过3个项目验证的生产级实现：

// src/history/HistoryStack.js export class HistoryStack { constructor(maxSize = 100) { this.stack = []; // 主栈：已执行命令 this.redoStack = []; // 重做栈：已撤销命令 this.maxSize = maxSize; // 防止内存爆炸 } push(command) { // 清空redo栈，因为新操作后无法重做之前的 this.redoStack = []; // 入栈前检查是否超过最大容量 if (this.stack.length >= this.maxSize) { this.stack.shift(); // 移除最老的命令 } this.stack.push(command); } canUndo() { return this.stack.length > 0; } canRedo() { return this.redoStack.length > 0; } undo() { if (!this.canUndo()) return null; const command = this.stack.pop(); try { command.undo(); this.redoStack.push(command); return command; } catch (error) { console.error('Undo failed:', error); // undo失败时，把命令放回stack，避免状态错乱 this.stack.push(command); throw error; } } redo() { if (!this.canRedo()) return null; const command = this.redoStack.pop(); try { command.execute(); this.stack.push(command); return command; } catch (error) { console.error('Redo failed:', error); this.redoStack.push(command); throw error; } } // 获取最近N条操作描述，用于UI显示 getRecentDescriptions(count = 10) { return this.stack.slice(-count).map(cmd => cmd.getDescription()); } // 清空所有历史（如新建文档时） clear() { this.stack = []; this.redoStack = []; } }

为什么undo()失败要放回stack？
这是血泪教训。某次线上事故：用户撤销时网络请求超时，undo()抛异常，stack被pop()但未执行成功，导致后续redo()找不到对应命令，整个撤销链断裂。现在改为“先pop()，再try，失败则push()回去”，确保stack状态始终与DOM一致。

maxSize设为100的依据？
通过埋点统计发现，95%的用户单次编辑会话中，操作数少于80次；设置100留有缓冲，同时避免长时间编辑占用过多内存。可根据项目需求调整，如笔记应用可设为500，代码编辑器可设为1000。

4.4 调用者（Invoker）与快捷键集成

调用者是用户与命令的桥梁。我们实现两个Invoker：工具栏按钮和键盘快捷键。

// src/invokers/ToolbarInvoker.js import { BoldCommand } from '../commands/BoldCommand.js'; import { ItalicCommand } from '../commands/ItalicCommand.js'; export class ToolbarInvoker { constructor(editor, historyStack) { this.editor = editor; this.historyStack = historyStack; } init() { // 绑定工具栏按钮 document.getElementById('btn-bold').addEventListener('click', () => { const command = new BoldCommand(this.editor); this.executeAndRecord(command); }); document.getElementById('btn-italic').addEventListener('click', () => { const command = new ItalicCommand(this.editor); this.executeAndRecord(command); }); } executeAndRecord(command) { try { command.execute(); this.historyStack.push(command); this.editor.notifyChange(); // 通知编辑器内容变更 } catch (error) { console.error('Command execution failed:', error); // 这里可触发UI错误提示 this.editor.showNotification('操作失败，请重试'); } } }

键盘快捷键需要处理keydown事件，并区分Ctrl/Cmd键：

// src/invokers/KeyboardInvoker.js export class KeyboardInvoker { constructor(editor, historyStack) { this.editor = editor; this.historyStack = historyStack; } init() { document.addEventListener('keydown', (e) => { // 检查是否按下Ctrl/Cmd + B if ((e.ctrlKey || e.metaKey) && e.key.toLowerCase() === 'b') { e.preventDefault(); // 阻止浏览器默认加粗 const command = new BoldCommand(this.editor); this.executeAndRecord(command); } // Ctrl+Z 撤销 if ((e.ctrlKey || e.metaKey) && e.key === 'z') { e.preventDefault(); this.historyStack.undo(); } // Ctrl+Shift+Z 重做 if ((e.ctrlKey || e.metaKey) && e.shiftKey && e.key === 'z') { e.preventDefault(); this.historyStack.redo(); } }); } executeAndRecord(command) { // 复用ToolbarInvoker的逻辑 try { command.execute(); this.historyStack.push(command); this.editor.notifyChange(); } catch (error) { console.error('Keyboard command failed:', error); } } }

关键技巧：e.preventDefault()的位置
必须在executeAndRecord()之前调用，否则浏览器可能先执行自己的execCommand('bold')，导致DOM状态与我们的命令不一致。这是调试时最常见的“撤销失效”原因。

4.5 宏命令（MacroCommand）实现批量操作

现在实现一个实用功能：“清除所有格式”。它需要依次执行“取消加粗”、“取消斜体”、“清除字体大小”等多个命令。

// src/commands/MacroCommand.js import { BaseCommand } from './BaseCommand.js'; export class MacroCommand extends BaseCommand { constructor(commands) { super(null); // 宏命令没有单一receiver，子命令各自持有 this.commands = commands; } execute() { this.commands.forEach(cmd => cmd.execute()); } undo() { // 逆序执行undo，确保逻辑正确 for (let i = this.commands.length - 1; i >= 0; i--) { this.commands[i].undo(); } } getDescription() { const descriptions = this.commands.map(cmd => cmd.getDescription()); return `宏命令: [${descriptions.join(', ')}]`; } // 支持动态添加子命令 addCommand(command) { this.commands.push(command); } } // 使用示例：清除所有格式 const clearFormatting = new MacroCommand([ new UnboldCommand(editor), new UnitalicCommand(editor), new ResetFontSizeCommand(editor) ]);

为什么undo()要逆序？
假设宏命令是[A, B, C]，execute()顺序是A→B→C。那么undo()必须是C→B→A，否则B的undo可能依赖C的状态。这是栈的天然特性，也是宏命令可靠性的基础。

5. 常见问题与排查技巧实录：那些文档里不会写的坑

5.1 典型问题速查表

5.2 我踩过的五个深坑及独家修复技巧

坑1：光标位置在撤销后丢失
现象：用户加粗一段文字后撤销，光标跑到页面顶部。
原因：undo()操作改变了DOM结构，浏览器重置了Selection。
修复技巧：在execute()前用rangy.saveSelection()保存选区，在undo()后用rangy.restoreSelection()恢复。rangy库专为此场景优化，比原生API稳定十倍。

坑2：异步命令的撤销时机错乱
现象：用户点击“发送邮件”命令（异步），然后立即撤销，但邮件已发出。
原因：execute()启动异步请求后立即返回，undo()在请求完成前执行，无法取消。
修复技巧：在命令中增加abortController，execute()中创建new AbortController()，将signal传给fetch；undo()中调用abortController.abort()。同时execute()返回Promise，undo()也返回Promise，确保调用方能await。

坑3：宏命令嵌套导致栈溢出
现象：宏命令A包含宏命令B，B又包含A，无限递归。
原因：缺少循环引用检测。
修复技巧：在MacroCommand.execute()开头加if (this._executing) throw new Error('Recursive macro detected')，执行前设this._executing = true，完成后delete this._executing。

坑4：移动端触摸事件触发双击
现象：iOS上点击加粗按钮，execute()被调用两次。
原因：click事件在触摸屏上有300ms延迟，touchend和click都被触发。
修复技巧：在ToolbarInvoker中统一用touchend替代click，并加e.preventDefault()；或使用fastclick库消除延迟。

坑5：序列化命令时丢失函数引用
现象：command.toJSON()后fromJSON()重建，execute()方法丢失。
原因：JSON标准不支持函数，toJSON()只序列化属性。
修复技巧：永远不要在命令对象中存函数。所有行为逻辑必须在类方法中，toJSON()只存数据。fromJSON()返回的是新实例，方法自然存在。

5.3 性能优化：当命令系统处理1000+操作时

在长文档编辑场景，历史栈可能积累上千条命令。这时必须优化：

1. 命令压缩（Command Compression）
连续的相同命令（如连续10次加粗）可合并为一个BoldCommand，参数count: 10。execute()中循环执行10次，undo()中循环undo10次。减少栈深度，提升遍历速度。

2. 历史快照（History Snapshot）
每100次操作，保存一次DOM快照（editor.getContent().substring(0, 10000)）。当用户跳转到很早的历史点时，不逐条undo()，而是直接加载快照，再执行后续命令。快照用LRU缓存，最多存5个。

3. 延迟序列化（Lazy Serialization）
toJSON()不立即执行，只在需要持久化（如页面卸载前）或同步到服务器