Command 接口应定义为 Execute() 和 Undo() 两个无参无返回值方法，参数通过结构体字段注入，错误在内部处理并记录到实例字段，避免运行时 panic。
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() 判空。
立即学习“go语言免费学习笔记（深入）”；
- 撤销栈定义为
[]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。
命令只负责“做什么”，不负责“用什么做”。执行环境（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）初始化命令，而不是在结构体里存指针
Undo 失败了怎么办？别 try-catch，要设计成可重入
Go 没有 try-catch，Undo() 执行出错（比如磁盘满导致回滚写失败）不能忽略，也不能让整个撤销流程卡死。正确做法是让 Undo() 尽可能幂等，并允许失败后仍能继续操作。
典型例子：文本编辑器里删除一行后 Undo，如果此时文件被外部程序锁住，Undo() 写回失败——用户得知道失败了，但不应因此无法再删下一行或保存文件。
-
Undo()内部不做 panic，失败时记录日志或设置字段undoErr error，但不中断流程 - 调用方检查
cmd.undoErr != nil后可提示用户“上次撤销未完全生效”，而不是停止响应 - 确保
Undo()可重复调用：比如写文件前先检查目标路径是否存在，存在则跳过或覆盖，避免第二次调用因文件已存在而报错
真正麻烦的是状态不一致：比如 Execute() 成功但 Undo() 失败，又没留备份。这时候靠命令自己救不了，得靠上层加 checkpoint 或事务日志——那已经超出 Command 模式职责了。
