Go中命令模式核心是将操作转为函数值，用type Command func()最轻量；需撤销时返回执行/撤销函数对，共享闭包状态；批量执行须逆序回滚，仅联动多步骤操作才值得封装。
Go 里命令模式不是用来“模拟 Java 风格接口继承”的，而是把操作变成值——能存、能传、能延迟调用、还能自带撤销逻辑。用对了很轻量，用错了反而多写一堆 struct 和 interface。
用 func() 类型代替 Command 接口最省事
90% 的场景根本不需要定义 type Command interface { Execute() }。Go 的函数是一等公民，直接用类型别名更自然、无抽象开销、闭包还能捕获上下文：
-
type Command func()就够了；需要返回值或错误时，改用func() error - 构造命令就是写个闭包：
saveCmd := func() error { return db.Save(user) } - 调用方完全不用知道背后是写 DB、发邮件还是打日志，只管执行
saveCmd() - 强行套用接口 + 多个 struct 实现，会导致每个小操作都要新建类型，测试难、维护累
需要撤销时，别在结构体里硬加 Undo() 方法
Go 没有虚函数机制，Undo() 方法无法被统一调度，除非你手动维护历史栈并显式调用。更 Go 的做法是：命令创建时就返回一对函数——执行和撤销，状态由闭包捕获：
java-api-doc-generator
下载
分析 Java Spring Boot 后端 Controller 代码，自动生成 Markdown 格式的接口文档。当用户说“生成 Java 接口文档”、“生成 API 文档”、“从 Spring 代码生成文档”时触发。
func NewCounterIncCommand(counter *int) (func(), func()) {
oldValue := *counter
execute := func() { *counter++ }
undo := func() { *counter = oldValue }
return execute, undo
}
- 撤销函数和执行函数共享同一份快照（如
oldValue），不依赖外部状态管理器 - IO 类型命令（如写文件）的
undo必须幂等且考虑失败路径，比如os.Remove失败不应 panic，而应返回 error - 如果命令本身要序列化或审计，才值得改用结构体封装
execute和undo字段
批量执行与原子回滚必须逆序调用 undo
用 []func() error 存命令队列很简单，但出错时回滚逻辑容易写错：
立即学习“go语言免费学习笔记（深入）”；
- 执行顺序是正向遍历切片，回滚必须从末尾开始逆序调用已成功执行的
undo函数 - 不能只靠
defer或recover，因为部分命令可能已生效，需显式补偿 - 建议封装一个
RunCommands(commands []func() error) error，内部自动记录成功索引，出错后按逆序调用对应undo - 涉及资源（如打开的文件、DB 事务）时，
undo应优先做清理，而非业务语义回退（那是上层逻辑的事）
真正难的不是怎么封装命令，而是判断哪些操作值得封装——比如 HTTP handler 中的一次数据库更新，通常没必要做成命令；但用户触发的“发布文章+发通知+更新统计”这一组联动操作，就适合用命令队列+统一错误处理+可选回滚来组织。状态捕获是否完整、undo 是否可重入、命令生命周期是否清晰，这些细节比结构体长得好不好看重要得多。
