Command 接口怎么定义才支持撤销重做
Go 没有抽象类或接口继承，但命令模式的核心在于统一行为契约：Execute() 和 Undo() 必须成对存在。只定义 Execute() 的接口无法支撑撤销逻辑，运行时调用 Undo() 会 panic。
正确做法是用一个接口囊括两个方法，并让所有具体命令实现它：
type Command interface {
Execute()
Undo()
}
- 不要把
Undo()做成可选方法（比如加CanUndo() bool），客户端代码会因此充斥类型断言和条件分支 - 如果某条命令天然不可逆（如发 HTTP 请求后无法撤回响应），应在
Undo()中明确记录日志或返回错误，而不是留空或 panic - 避免在接口里塞
Redo()—— 它本质是再次Execute()，额外方法只会增加实现负担
撤销栈里该存指针还是值
存 *MyCommand 而不是 MyCommand。命令对象通常携带状态（比如被操作的文档、坐标、原始值），值拷贝会让 Undo() 操作失效 —— 它改的是副本，不是原始执行时修改的那个实例。
典型错误现象：Execute() 修改了结构体字段，但 Undo() 发现字段值没变，因为 undo 调用的是另一个副本。
立即学习“go语言免费学习笔记（深入）”；
- 所有命令实例应通过
&MyCommand{...}获取指针后入栈 - 撤销栈本身用
[]Command即可（接口切片能容纳任意实现），不必用[]*Command - 注意：如果命令内部持有大对象（如 []byte），指针共享没问题；但若需隔离执行/撤销上下文，就得手动深拷贝，这不是模式问题，是业务约束
如何安全地管理命令生命周期和资源
Go 没有析构函数，命令对象若持有文件句柄、网络连接或 goroutine，Undo() 执行后不清理，会导致资源泄漏。常见场景是命令启动了一个后台监听，撤销时却没关掉。
解决思路不是靠 GC，而是显式约定资源管理责任：
-
Execute()分配的资源，必须由Undo()对应释放（如os.Open→file.Close()） - 避免在命令里启动长期 goroutine；真需要，用
context.Context控制生命周期，并在Undo()中 cancel - 如果命令执行失败（
Execute()panic 或返回 error），它不该进撤销栈 —— 否则后续Undo()会操作半初始化状态，直接 crash
为什么不能直接用 slice 当撤销栈
用 []Command 存命令没问题，但“当撤销栈”意味着要支持从尾部弹出、清空历史、限制长度。直接操作 slice 容易踩坑：
错误示例：history = history[:len(history)-1] 看似删最后一个，但底层底层数组未释放，旧命令对象可能被意外保留（尤其当命令含指针字段时）。
- 每次
Undo()后，显式置空已弹出项：history[i] = nil，帮助 GC 识别不可达对象 - 限制最大长度时，用
append(history[:0], newCmd)重用底层数组，比反复 make 更省内存 - 撤销后禁止再执行新命令时不清空前方历史（即“分叉”问题），否则重做无意义 —— 这得靠上层逻辑控制，不是命令接口能解决的
真正麻烦的从来不是怎么写 Undo()，而是谁来保证命令之间没有隐式共享状态、以及撤销边界是否清晰。这点在涉及并发或跨 goroutine 修改同一数据时尤其容易翻车。
