go中用command接口实现技能释放与撤销需定义含execute()和undo()方法的接口，命令仅持状态引用而非拷贝，撤销栈用切片实现，避免interface{}导致类型丢失，高频命令用sync.pool复用以减gc压力。
Go 里怎么用 Command 接口实现技能释放与撤销
Go 没有内置的 Command 模式，得自己定义接口。核心就两条：每个技能封装成一个实现了 Execute() 和 Undo() 方法的结构体；所有命令统一存进栈里，方便按序回退。
常见错误是把状态直接存在命令对象里，结果多个命令互相污染。正确做法是让命令只持有「必要上下文引用」（比如指向角色状态的指针），而不是拷贝状态。
-
Execute()负责修改游戏世界状态，比如扣血、生成特效、更新冷却时间 -
Undo()必须严格逆向执行，不能只靠“恢复上一帧”，得靠命令自己记下变更前的值（如扣血前的 HP） - 撤销栈建议用
[]Command切片 +append()/slice[:len(slice)-1]，别用链表——GC 压力大，且游戏逻辑对 O(1) 弹出有硬需求
为什么不用 interface{} 存命令，而要用具体接口类型
用 interface{} 看似灵活，实际会丢失类型信息，导致 Undo() 调用时 panic 或静默失败。尤其在热更技能逻辑或加新命令类型时，编译器完全没法帮你检查。
真实场景中，技能可能分「瞬发」「引导」「持续」三类，每类 Undo() 行为完全不同：瞬发技能要还原属性；引导技能得中断计时器；持续技能得清除 tick goroutine。这些差异必须靠接口约束暴露出来。
立即学习“go语言免费学习笔记（深入）”；
- 定义
type Command interface { Execute() error; Undo() error }，强制所有技能实现两个方法 - 避免在接口里塞
String()或Type()这类辅助方法——它们会诱使业务代码做类型断言，破坏命令的正交性 - 如果某技能不需要撤销（比如“退出游戏”），就让它的
Undo()返回errors.New("not undoable")，而不是留空或 panic
Redo 支持要不要加？什么时候加反而坏事
加 Redo 听起来完整，但游戏里极少真正需要。用户按下 Ctrl+Z 再 Ctrl+Y，本质是「撤销后立刻重放」，靠复用原命令对象 + 栈顶缓存就能实现，不用额外字段或状态机。
真正踩坑的是强行支持 Redo 导致命令变复杂：比如引导技能被撤销后，原计时器已停，Redo() 得重新启动并校准剩余时间——这会让单个命令承担太多时序逻辑，和「单一职责」冲突。
- 优先实现
Undo()的幂等性和可重入性，比搞Redo()实用十倍 - 如果 UI 层真要显示「重做可用」，只需监听撤销栈是否非空 + 上次操作是否成功，无需命令本身参与
- 多人协作编辑技能配置时，
Redo会和同步状态冲突，此时应直接禁用，而不是花精力做分布式命令重放
性能敏感点：命令对象分配和 GC 压力怎么压
战斗中每秒可能触发几十次技能，每次 new 一个命令结构体，很快触发 GC。实测在 60fps 下，频繁分配会导致卡顿帧，尤其在低端 Android 设备上。
解决思路不是池化所有命令（类型太多难管理），而是把高频命令（如普攻、闪避）做成「预分配 + 复位」模式，其他低频技能（如大招）仍走 new。
- 用
sync.Pool管理普攻命令实例，Get()后调用Reset(*Player)方法重置目标和参数 - 避免在命令里存闭包或匿名函数——它们会隐式捕获变量，延长对象生命周期
- 所有时间相关字段（如
startTime time.Time）改用int64纳秒戳，减少time.Time的内存开销和比较成本
最易忽略的是命令栈本身：别在每帧都新建切片，用 make([]Command, 0, 32) 预分配容量，再反复 clear() 复用底层数组。
