Go实现撤销恢复需用命令对象封装操作，每个命令实现Execute()、Undo()、Redo()方法，要求幂等、深拷贝状态、单slice+索引管理栈、错误隔离、显式命令类型标识，并仅对有状态变更的操作入栈。
撤销恢复必须用命令对象封装操作
Go 没有内置的 undo/redo 机制，硬靠全局状态或函数指针来回跳很容易失控。核心是把每个可撤销动作包装成实现了 Execute()、Undo()、Redo() 的结构体，而不是直接调用逻辑函数。
- 每次用户输入（比如
add user --name=alice）都应生成一个新命令实例，而不是复用旧对象 -
Undo()和Redo()必须是幂等的：重复调用不能导致状态错乱（例如删两次同个用户会 panic） - 命令对象里不要存指针引用外部状态，而要深拷贝关键数据——比如操作前先读取当前
users列表快照，而不是只存一个*[]User - 如果命令依赖外部服务（如写文件、发 HTTP 请求），
Undo()要能反向补偿（删文件、撤回 webhook），不能只“假装没发生”
命令栈要用 slice + 索引控制，别用双栈模拟
网上常见用两个栈（undoStack、redoStack）来回倒腾，但在 CLI 场景下容易丢操作、索引错位，尤其涉及 redo 后又新执行命令时。
- 推荐单 slice 存所有命令：
commands []Command，加一个currentIndex int指向“当前已执行到哪条” -
Undo()就是commands[currentIndex].Undo()后currentIndex--；Redo()是currentIndex++后commands[currentIndex].Redo() - 新命令插入时，先截断
commands = commands[:currentIndex+1]，再append——否则 redo 历史会残留失效路径 - slice 容量增长本身不贵，但频繁
append后又[:n]截断可能引发内存泄漏，建议定期commands = append([]Command(nil), commands...)强制重分配
CLI 参数解析失败会导致命令构造中断，undo 栈必须隔离错误
用户输错参数（比如 delete user --id=abc）时，根本走不到 Execute()，但如果此时已往栈里 push 了命令实例，就会让 undo 链断裂或执行空操作。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 命令实例化（
NewDeleteUserCmd(...)）和参数校验必须在Execute()外完成，且失败时不入栈 - 推荐模式：
cmd, err := ParseCommand(os.Args)→ 校验err→ 成功才stack.Push(cmd)→ 最后cmd.Execute() - 不要在
Execute()里做参数解析：它只负责改变状态，不负责纠错；否则Undo()无法匹配执行时的真实输入上下文 - 如果命令含副作用（如发通知），应在
Execute()开头用defer注册补偿逻辑，确保 panic 时也能清理，但注意 defer 不会触发Undo()
字符串命令名必须唯一且稳定，否则 redo 会错乱
有些实现用 reflect.TypeOf(cmd).String() 当命令类型标识，但包路径变化、重构重命名会让历史命令无法识别，导致 redo 执行错误函数。
立即学习“go语言免费学习笔记（深入）”；
- 给每个命令类型定义常量名：
const CmdTypeDeleteUser = "delete_user"，并在序列化/日志中固定使用 - 命令结构体里显式存
Type string字段，而不是靠反射推导 - 如果支持持久化命令历史（比如存到磁盘供重启后恢复），
Type就是反序列化的路由键，拼错一个字符就整个链失效 - 避免用命令参数值（如
"delete_user_alice"）当类型名——参数变，类型就变，undo/redo 逻辑会认为是全新命令
最麻烦的不是写 Undo()，而是判断哪些操作真需要它。比如 help 或 list --format=json 这种纯读操作，塞进栈里只会污染历史、拖慢性能。得在命令注册时就标清 IsStateful bool，栈只收它为 true 的实例。
