Go中命令模式核心是定义无参无返回值的Command接口，通过结构体封装Receiver和参数实现解耦，Invoker仅依赖接口执行命令，Undo需命令自行保存上下文。
Go 语言没有内置的命令模式（Command Pattern）支持，但用接口 + 结构体能干净解耦调用者（Invoker）和执行者（Receiver），关键在于把「做什么」和「谁来做」彻底分离。
如何定义 Command 接口与基础实现
核心是抽象出统一的执行契约。Go 里最自然的方式是定义一个无参、无返回值的函数接口：
type Command interface {
Execute()
}
所有具体命令都实现它。注意：不要带参数或 error 返回——参数应封装进结构体字段，错误应在 Execute() 内部处理或通过字段/回调暴露。否则调用者又得感知具体命令的签名，破坏解耦。
典型封装方式：
立即学习“go语言免费学习笔记（深入）”；
-
Receiver实例作为字段嵌入命令结构体（组合优于继承） - 必要参数在创建命令时传入并保存为字段（如
file string,timeout time.Duration） - 避免在
Execute()中再传参——那说明封装不完整
调用者（Invoker）如何做到完全不知晓 Receiver
Invoker 只依赖 Command 接口，不 import 任何具体 Receiver 包。它只做三件事：接收命令、排队、触发 Execute()。
type Invoker struct {
commands []Command
}
func (i *Invoker) Add(cmd Command) {
i.commands = append(i.commands, cmd)
}
func (i *Invoker) ExecuteAll() {
for _, cmd := range i.commands {
cmd.Execute()
}
}
常见错误：
- Invoker 直接调用
receiver.DoSomething(...)—— 这根本不是命令模式，只是普通函数调用 - Invoker 根据命令类型做
switch cmd.(type)分支处理 —— 又把逻辑拉回调用侧，违背解耦初衷 - 把
Invoker设计成单例或全局变量 —— 难以测试，状态易污染
Undo / Redo 支持必须靠命令自己保存上下文
Go 没有自动栈帧或反射式状态快照，Undo() 能否实现，完全取决于命令是否在 Execute() 前主动记录了足够信息。
比如文件重命名命令：
type RenameCommand struct {
fs FileSystem // 接口，便于 mock
oldName string
newName string
// Undo 所需：执行前确认 oldName 存在，并记录原始状态（如 FileInfo）
originalInfo os.FileInfo
}
func (r *RenameCommand) Execute() error {
info, err := r.fs.Stat(r.oldName)
if err != nil {
return err
}
r.originalInfo = info // 保存用于 Undo
return r.fs.Rename(r.oldName, r.newName)
}
func (r *RenameCommand) Undo() error {
return r.fs.Rename(r.newName, r.oldName)
}
重点：
-
Undo()不是Command接口的一部分——按需添加，避免强契约 - 状态保存必须在
Execute()内完成，不能依赖外部时机 - 如果 Receiver 是无状态服务（如 HTTP client），Undo 几乎不可行，得换思路（如用事务 ID 回滚）
命令创建与参数传递的边界在哪
命令对象本身应是「可序列化、可缓存、可复用」的。因此构造时就该收齐所有依赖：
- Receiver 实例（如
*DB,*HTTPClient）—— 必须传入，不能延迟 resolve - 运行时才知的参数（如用户输入）—— 应在
Execute()前通过方法注入，或由上层组装好完整命令 - 避免在命令里 new 出 receiver（如
&sql.DB{...}）—— 破坏控制反转，难以 stub
反例：NewDeleteUserCommand(userID int) 是错的；正确是 NewDeleteUserCommand(db *sql.DB, userID int)。
真正难的从来不是写个 Execute() 方法，而是想清楚哪些数据属于命令生命周期，哪些该交给调用链上游决定。一不留神，命令就退化成带字段的函数调用。
