如何在Golang中实现命令模式Command Go语言操作封装与撤销-Golang-PHP中文网

Command 接口应定义为 Execute() 和 Undo() 两个无参无返回值方法，参数通过结构体字段注入，错误在内部处理并记录到实例字段，避免运行时 panic。

如何在golang中实现命令模式command go语言操作封装与撤销

Command 接口怎么设计才不踩 runtime panic 坑

Go 没有抽象类，靠接口模拟 Command 模式时，最常掉进的坑是：接口方法签名不一致导致 Execute() 和 Undo() 在具体实现里漏写、参数错位，或返回值类型不匹配——运行时才 panic，而且堆栈不指向命令本身。

必须让所有命令都满足同一契约：两个无参、无返回值的方法是最安全起点。如果真需要传参，统一用结构体字段初始化，而不是塞进方法签名。

Execute() 和 Undo() 都声明为 func()，不带参数也不返回 error
实际执行逻辑里的错误（比如文件写失败）应提前在 Execute() 内部处理并记录到命令实例字段（如 err error），而非靠返回值传递
避免在 Undo() 里做“反向计算”，而是依赖 Execute() 执行后保存的原始状态快照（如旧值、旧位置）

撤销栈用 slice 还是 list？为什么别碰 container/list

用 container/list 管理命令历史看似“标准”，但实际会多出大量类型断言和指针解引用，一不小心就 nil panic；而 Go 的 slice 配合 append() 和切片截断（history = history[:len(history)-1]）更直接、内存局部性更好、GC 压力更低。

关键不是“能不能用”，而是“改起来顺不顺”“查 bug 方便不方便”。slice 的索引可直接打印调试，list 的迭代必须写循环且容易漏 Next() 判空。

撤销栈定义为 []Command，不是 *list.List
执行新命令时：history = append(history, cmd)
撤销时：if len(history) > 0 { last := history[len(history)-1]; last.Undo(); history = history[:len(history)-1] }
重做（redo）需额外维护一个 redoStack []Command，且每次 Undo() 后要把命令 push 进去，Redo() 再 pop 出来执行

命令对象里该不该存 http.Client 或 sql.DB？

存了就等于把外部依赖和生命周期耦合进命令实例，导致测试难、复用差、内存泄漏风险高——比如一个数据库命令持有了已关闭的 *sql.DB，后续 Execute() 直接 panic。

Golang Uber Dig

使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等

下载

命令只负责“做什么”，不负责“用什么做”。执行环境（client、db、logger）应该由调用方注入，或者通过闭包捕获，而不是固化在命令结构体字段里。

命令结构体字段只放数据：如 FileName string、OldContent []byte、RowID int64
执行时所需依赖（如 *sql.Tx）应作为 Execute() 的隐式上下文传入——常见做法是定义 type Command interface { Execute(ctx context.Context, deps Deps) }，其中 Deps 是个轻量 struct
如果硬要共享资源，用函数选项模式（functional options）初始化命令，而不是在结构体里存指针