go中命令模式用func()或含do/undo字段的struct实现，不依赖接口继承；func()最轻量，闭包捕获上下文，结构体适用于需撤销、持久化等场景。
Go 里命令模式不是靠接口继承或抽象类，而是用 func() 或带 Do/Undo 字段的 struct 就能干净落地。硬套 Java 那套 Command 接口 + 多个实现 struct，反而让代码变重、难测、易出错。
用 func() 类型封装一次性命令最轻量
90% 的简单场景根本不需要定义接口或 struct——func() 本身就是命令。它天然支持闭包捕获上下文，调用方只认类型，不关心内部是写文件、发 HTTP 还是改内存变量。
- 直接定义：
type Command func()，然后cmd := func() { fmt.Println("hello") } - 传参靠闭包绑定，别在循环里漏掉变量复制：
for _, id := range ids { id := id; cmds = append(cmds, func() { process(id) }) } - 避免把
*sql.DB或*http.Client塞进闭包里长期持有；执行时再传入更安全，也方便测试 mock - 函数值无法序列化，也不带元数据（比如超时、重试次数），所以日志审计、MQ 发送、持久化历史等场景必须换结构体
需要撤销时，优先用 struct{ Do, Undo func() }
不要定义 type Command interface { Execute(); Undo() }——这会导致每个命令都要写 struct 实现，Undo 逻辑和执行逻辑强行耦合，且运行时容易漏实现或签名不一致导致 panic。
- 正确姿势是：命令创建时就捕获快照，比如
oldName := user.Name，Undo闭包里直接赋值回去 -
Undo必须基于“当时值”，不是“当前值”。若闭包里引用了&user，Undo 时操作的可能是已被后续修改过的对象 - 结构体字段只存数据（
FileName string,RowID int64），不存接收者指针；依赖项（如*sql.Tx）应在Do执行时作为参数传入，或由闭包按需捕获 - 如果
Undo逻辑复杂或需额外上下文，改用带参函数类型，比如type UndoFunc func(*State)，但多数情况func()足够
撤销栈必须用 []Command，别碰 container/list
用 container/list 管理历史看似“标准”，实际调试困难、GC 压力大、容易 nil panic，而且索引访问不直观。
- 撤销栈定义为
history []Command，新增命令：history = append(history, cmd) - Undo 操作：
if len(history) > 0 { last := history[len(history)-1]; last.Undo(); history = history[:len(history)-1] } - Redo 需额外维护
redoStack []Command，每次 Undo 后把命令 push 进去，Redo 时 pop 并执行Do - 用户执行新命令前，必须清空
redoStack——这是行为常识，不是可选项
批量执行出错时，回滚必须逆序调用 Undo
执行顺序是正向遍历切片，但出错后已生效的命令必须从最后一个往前 undo，否则状态不一致。这不是靠 defer 或 recover 能解决的。
- 不能写成：
for _, cmd := range executed { cmd.Undo() }（这是正序，错） - 正确写法：
for i := len(executed)-1; i >= 0; i-- { executed[i].Undo() } - IO 类型命令（如写文件、删记录）的
Undo必须幂等：重复调用不应 panic，失败也要返回 error 而非静默忽略 - 真正难的不是封装命令，而是判断哪些操作值得封装——单次 DB 更新通常不用；但“发布文章 + 推送通知 + 更新统计”这种多步骤联动，才需要命令队列 + 原子回滚
最容易被忽略的是状态快照的时机：Undo 的准确性完全取决于命令初始化那一刻是否拷贝了所有关键字段。闭包里引用指针、全局变量、或未显式复制的 struct 字段，都会让 Undo 变成“撤了个寂寞”。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
