go中命令模式通过func()类型和结构体组合实现解耦，核心是将行为封装为可传递、存储、延迟执行的值；支持撤销需显式保存undo逻辑，异步执行需防goroutine泄漏，依赖应闭包捕获而非全局查找。
命令模式在 Go 里不是靠接口继承或抽象类实现的，而是靠函数类型和结构体组合自然达成解耦——关键不在“定义命令接口”，而在“把行为封装成可传递、可存储、可延迟执行的值”。
用 func() 类型代替传统 Command 接口
Go 没有强制的 Command 接口，但 func() 本身已是“无参无返回”的命令契约。它比 Java/C# 的 execute() 更轻量，也更符合 Go 的组合哲学。
- 定义命令：直接用
type Command func()，无需额外结构体包装 - 封装行为：闭包捕获上下文（如 receiver、参数），避免暴露内部状态
- 延迟执行：把
Command存进切片、map 或 channel，调用时才触发
示例：
type Light struct{ on bool } func (l *Light) TurnOn() { l.on = true } func (l *Light) TurnOff() { l.on = false } // 封装为 Command var turnOnCmd Command = func() { light.TurnOn() } var turnOffCmd Command = func() { light.TurnOff() }
支持撤销的命令需携带反向操作逻辑
纯 func() 不自带撤销能力，必须显式保存“怎么 undo”。常见做法是让命令结构体同时持有 execute 和 undo 两个函数字段。
立即学习“go语言免费学习笔记（深入）”；
- 撤销不是默认行为，得由调用方主动管理历史栈（如
[]Command） - 注意资源生命周期：如果
execute分配了内存或打开了文件，undo必须能安全释放 - 不要在
undo里重试失败操作——它应是幂等的回退，不是补偿事务
示例：
type UndoableCommand struct { execute func() undo func() } func (c UndoableCommand) Do() { c.execute() } func (c UndoableCommand) Undo() { c.undo() } // 使用 cmd := UndoableCommand{ execute: func() { file.Write(data) }, undo: func() { file.Truncate(0) }, // 简化示意，实际需记录原长度 }
命令队列与异步执行要小心 goroutine 泄漏
把命令发到 chan Command 后用 goroutine 消费很常见，但容易忽略退出控制和 panic 恢复。
- 务必用
select+donechannel 控制生命周期，避免 goroutine 永驻 - 每个
Command执行前加defer func(){ recover() }()，否则一个 panic 会让整个队列卡死 - 不要在命令闭包里直接引用外部循环变量（如
for _, v := range items { cmds = append(cmds, func(){ use(v) }) }），要用局部副本
和依赖注入结合时，避免命令持有所谓“Service Locator”
有些实现会把 *ServiceManager 或全局容器塞进命令结构体，这反而破坏了解耦。正确做法是：在创建命令时，通过闭包捕获所需依赖实例。
- 命令只该知道自己要调什么方法，不该知道服务从哪来
- 依赖应在初始化阶段注入（如工厂函数参数），而不是运行时查表获取
- 测试时可直接传入 mock 对象，无需替换全局状态或改配置
错误示范：cmd := &DBCommand{svc: globalServiceLocator.Get("db")}
正确做法：cmd := func(db *DB) Command { return func() { db.Save(...) } }(mockDB)
命令模式在 Go 里真正难的不是写法，而是判断什么时候该把逻辑抽成命令——比如是否需要重试、审计、排队、撤销，或者只是单纯想把 if/else 拆开。这些决策比语法更重要。