go中命令模式的核心是func()类型而非接口，应使用struct{do, undo func()}封装命令，用两个slice管理历史与重做栈，并在创建时捕获状态快照以确保撤销准确性。
Go 里命令模式的核心不是接口，是 func() 类型
Go 没有抽象类、没有方法重写，硬套 Java 那套 Command 接口 + Execute()/Undo() 方法会写得很别扭。真正轻量又符合 Go 习惯的做法，是把命令看作可执行的闭包：func() 就是命令本身，func() 的逆操作（比如回滚逻辑）也用另一个 func() 表达。
常见错误是试图定义 type Command interface { Execute(); Undo() }，然后为每个操作写 struct 实现——这不仅冗余，还让撤销逻辑和执行逻辑强行耦合在同一个类型里，反而难维护。
实操建议：
- 用两个独立的
func()字段表示“做”和“撤”，例如struct{ Do, Undo func() } - 命令创建时就捕获所有依赖状态（如原值、ID、上下文），避免后期调用时闭包变量已变
- 如果 Undo 逻辑复杂或需传参，不要塞进闭包，改用带参数的函数类型，比如
type UndoFunc func(*State)，但多数简单场景func()足够
撤销栈必须用 slice 而不是 map 或 channel
重做/撤销本质是线性历史记录，[]Command 是最自然的选择。有人用 map[int]Command 想支持随机跳转，或者用 chan Command 想搞异步命令流——这都会破坏“上一步/下一步”的语义，导致 Redo() 不可预测或丢命令。
典型错误现象：Undo() 后 Redo() 失效、连续两次 Undo() 跳过中间步骤、清空历史后新命令无法重做。
实操建议：
- 维护两个 slice：
history []Command（已执行）、redoStack []Command（被 Undo 过的） -
Undo()从history弹出最后一个，执行其Undo，再推入redoStack -
Redo()从redoStack弹出，执行其Do，再推入history - 每次新命令执行前，清空
redoStack（用户新操作后旧重做失效是常识）
命令对象里别存指针或全局状态
如果命令闭包里引用了 *User 或 db 全局变量，Undo 时很可能操作的是当前最新状态，而不是命令执行时的快照。比如：命令执行时 user.Name = "A"，Undo 应设回旧值；但如果闭包里直接用了 &user，Undo 时 user.Name 可能已是 "B" 了。
使用场景：编辑器文本变更、表单字段修改、数据库记录更新——这些都需要“当时值”而非“当前值”。
实操建议：
- 命令初始化时显式拷贝关键字段：
oldName := user.Name，Undo 时赋值回去 - 对结构体，用值拷贝（
u := *user）比存*user更安全；必要时深拷贝（json.Marshal/Unmarshal或copier.Copy） - 避免在命令里调用外部服务或读写共享缓存，这些行为不可逆且难以测试
Go 标准库没提供命令模式工具，但 undo 包太重，自己写 30 行够用
查 go get undo 会找到几个第三方包，但它们往往带状态管理、事件通知、序列化等你不需要的功能，还强依赖特定结构体 tag 或接口。实际项目里，一个带 Do/Undo 字段的 struct 加上两个 slice 管理，不到 30 行就能跑通核心流程。
性能影响很小：slice append/pop 是 O(1)，闭包调用开销可忽略；兼容性零问题，纯 Go 代码，无 CGO 或版本锁死。
实操建议：
- 定义
type Command struct{ Do, Undo func() }，不加任何方法 - 撤销管理封装成独立 struct：
type History struct{ history, redoStack []Command }，只暴露Push(c Command)、Undo()、Redo() - 测试时直接构造
Command{Do: func(){...}, Undo: func(){...}}，不用 mock 任何东西
真正麻烦的从来不是写命令模式，而是决定哪些操作值得封装、哪些状态要快照、Undo 失败时怎么降级——这些没法靠框架解决，得看业务边界划在哪。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
