命令模式在任务调度系统中通过封装“调度动作”为带状态快照的命令对象实现撤销重做，调度器用双栈管理历史与重做命令，对不可逆操作采用补偿命令，命令需支持序列化与幂等。
命令模式在任务调度系统中实现撤销重做，关键不是让“任务”可逆，而是把“调度动作”本身封装为带状态快照的命令对象，并由调度器统一管理执行与回退逻辑。
命令对象必须保存执行前的完整上下文
调度系统中的任务往往涉及外部依赖（如数据库更新、HTTP调用、文件写入），这些操作天然不可逆。命令模式不试图反转它们，而是聚焦于“调度决策”的可撤销性——比如“启动某定时任务”“暂停某工作流”“修改任务参数”。
- 每个命令需在 execute() 调用前 明确捕获关键状态：原任务配置、当前启用状态、上次执行时间、关联资源 ID 等
- 避免在 undo() 中重新查询数据库或远程服务；应直接使用命令内部缓存的字段还原调度元数据
- 示例：一个
EnableJobCommand会保存jobId和wasEnabledBefore布尔值，undo 就是调用jobService.setEnabled(jobId, wasEnabledBefore)
调度器（Invoker）用双栈结构隔离历史与待重做
任务调度器作为 Invoker，不执行业务逻辑，只维护两个独立栈：
- historyStack：存储已成功 execute 的命令（强引用需谨慎，建议用轻量数据对象或弱引用包装）
- redoStack：仅存放刚被 undo 的命令；一旦新命令 execute，该栈立即清空
- 每次 execute 后：push 到 historyStack，同时 clear redoStack
- undo 操作：pop historyStack → 调用其 undo() → push 到 redoStack
- redo 操作：pop redoStack → 调用其 execute() → push 回 historyStack
对真正不可逆操作，用补偿命令替代直接回滚
如果命令触发了发邮件、扣款、推送通知等副作用，不能靠 undo() 撤销结果，而应设计配套的补偿命令：
- 原始命令：
SendNotificationCommand，执行发送并记录通知 ID - 补偿命令：
RevokeNotificationCommand，根据通知 ID 调用撤回接口或发送更正消息 - 在 undo() 中不尝试“取消已发出的 HTTP 请求”，而是 new 一个补偿命令并同步 execute 它
- 可在 Command 接口增加
isUndoable(): boolean方法，供调度器跳过无法补偿的操作
支持队列化调度时，命令需具备序列化与幂等能力
当任务通过消息队列异步执行，命令对象要能跨进程传递：
- 命令类应实现
Serializable或转为 JSON 可序列化的 DTO（如UpdateJobConfigCmdDto） - 接收者（如 JobSchedulerService）需保证 execute() 幂等：同一命令重复触发不应产生副作用
- undo() 也应幂等，防止网络重试导致状态错乱
- 建议在命令中加入唯一 traceId 和时间戳，便于日志追踪与去重
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
