Go中命令模式无需接口，可用函数类型或结构体实现：func()适合简单操作，结构体+Execute()/Undo()支持带状态和撤销的命令，需注意上下文捕获、错误处理及context生命周期对齐。
命令模式在Go里为什么不用接口也能玩得转
Go没有传统OOP的抽象类或强制接口实现，但命令模式的核心——“把请求封装成对象”——完全可以通过函数类型和结构体组合达成。关键不是模仿Java写法，而是抓住Command的本质：延迟执行、可存储、可撤销、可排队。
常见错误是硬套UML图，定义一堆空接口比如Command、Receiver、Invoker，结果每个都要写冗余方法，反而失去Go的简洁性。
- 用
func()作为最轻量的命令载体，适合无参数、无返回值的简单操作 - 需要传参或支持撤销时，改用结构体字段存状态，搭配
Execute()和Undo()方法 - 避免为“模式而模式”加不必要的层级，比如
Invoker往往直接是业务逻辑里的一个切片或map
如何用结构体+方法实现带撤销的命令
当命令需要记住上下文（比如编辑器里的文本变更、文件系统中的路径），结构体比闭包更可控，也更容易测试。
示例：一个简单的文件重命名命令
type RenameCommand struct {
oldPath string
newPath string
backup string // 撤销时用
}
func (r *RenameCommand) Execute() error {
if err := os.Rename(r.oldPath, r.newPath); err != nil {
return err
}
r.backup = r.oldPath // 实际中建议用临时文件备份内容
return nil
}
func (r *RenameCommand) Undo() error {
return os.Rename(r.newPath, r.backup)
}
-
Execute()和Undo()方法名不强制，但保持一致利于团队理解 - 注意
Undo()是否幂等；上面例子没处理oldPath已存在的情况，真实场景需预检查 - 结构体字段应只存必要状态，避免捕获大对象（如整个
*http.Request）导致内存泄漏
用函数值列表做命令队列时的陷阱
把[]func()当命令队列很常见，但容易忽略执行时机和错误处理边界。
典型问题：for _, cmd := range cmds { cmd() } 看似正确，但一旦某个cmd() panic，后续命令全被跳过，且无法知道哪一步失败。
- 执行前先做
nil检查：if cmd != nil { cmd() } - 用
recover()包裹单个命令执行，避免中断整个队列 - 如果命令有返回值（如
error），别丢弃它；建议用[]func() error并收集所有错误 - 注意闭包捕获变量的陷阱：循环中创建命令时，别直接引用循环变量
i或v，应显式拷贝
命令和context.Context怎么安全配合
网络请求、数据库操作这类命令常需超时控制或取消信号，但context.Context不能直接塞进func()签名——会破坏命令的通用性。
解决办法是把context.Context作为命令结构体字段，而非函数参数：
type APICallCommand struct {
ctx context.Context
url string
result *string
}
func (a *APICallCommand) Execute() error {
req, _ := http.NewRequestWithContext(a.ctx, "GET", a.url, nil)
resp, err := http.DefaultClient.Do(req)
// ...
}
- 不要在
Execute()里重新context.WithTimeout，除非你明确要覆盖调用方传入的ctx - 若命令本身要启动goroutine，务必用
ctx.Done()监听取消，而不是靠外部杀goroutine - 结构体里存
context.Context没问题，但它不该被序列化或跨进程传递
真正难的是命令生命周期和context生命周期的对齐——比如一个命令被加入队列后，原始ctx已cancel，但队列还没轮到它执行。这时候该拒绝执行，还是记录错误，取决于业务语义。
