go中应用状态模式需定义仅含handle方法的state接口，显式返回新状态，避免隐式修改；用context共享数据，通过接口注入依赖，强制编译期检查事件处理，测试覆盖非法事件序列以确保状态流转安全可靠。
Go 里怎么用状态模式避免 if-else 堆成山
状态模式在 Go 里没有语言级支持，但恰恰因此更需要你主动设计接口和切换逻辑。核心不是“实现模式”，而是让状态变更可预测、可测试、不隐式泄露。
常见错误是把 State 设计成带大量方法的 struct，每个方法都判断当前状态再分支——这等于把 if 搬进方法里，没解决问题。
- 真正有效的做法：定义
State接口，只暴露一个Handle方法，输入是事件（如EventAttack），输出是新状态（State）或错误 - 所有状态流转必须显式返回下一个
State，禁止在内部直接修改上下文的currentState字段 - 游戏 AI 中典型场景：NPC 从
IdleState→ 收到EventPlayerNearby→ 返回AlertState→ 再收到EventPlayerInSight→ 返回ChaseState - 别在
Handle里做耗时操作（比如路径寻路），先切状态，再由主循环或 goroutine 异步处理；否则状态机卡住，AI 停滞
为什么不用 map[string]func() 而要写接口+struct
用字符串查表或闭包映射看起来更轻量，但在游戏 AI 这类需长期运行、频繁切换、多人协作的代码里，很快会失控。
典型现象：panic: interface conversion: interface {} is nil, not *ai.ChaseState —— 因为 map 里漏写了某个事件的 handler，运行时才崩。
立即学习“go语言免费学习笔记（深入）”；
- 接口强制编译期检查：新增事件类型后，所有
State实现必须补上对应Handle方法，否则编译失败 - struct 组合比闭包更容易注入依赖：比如
ChaseState需要*Pathfinder，直接作为字段传入，测试时可 mock - 性能差异微乎其微：一次状态切换的函数调用开销远小于路径计算或动画播放，别过早优化这里
- Go 的接口是隐式实现，别为了“统一”给所有状态加一堆空方法；每个
State只实现它真需要响应的事件
状态切换时怎么安全共享数据
AI 行为经常需要跨状态传递临时信息：比如 AlertState 发现玩家位置，ChaseState 要接着追。不能靠全局变量，也不能靠状态 struct 之间互相强引用。
常见坑：panic: assignment to entry in nil map 出现在 ctx.Data["targetPos"] = pos，因为忘了初始化 ctx.Data。
- 推荐做法：用一个轻量
Context结构体承载生命周期与状态机等长的数据，如TargetID、LastSeenAt、StunTimer -
Context本身不实现状态逻辑，只被各State读写；它的字段应尽量不可变（如用time.Time而非自增计数器） - 避免在
Handle中修改Context后立刻触发新行为（如设了TargetID就马上调用寻路）；主循环应在状态切换后统一检查并响应 - 如果多个状态都要改同一字段，考虑把它抽成独立 service（如
*HealthManager），通过接口注入，而非塞进Context
测试状态流转时最容易漏掉的边界
单元测试常覆盖「正常流程」，但游戏运行中更常出问题的是异常组合：比如玩家突然消失、网络延迟导致重复事件、状态还没切完就被强制重置。
典型错误：TestChaseState_HandleEventPlayerLost fails: expected IdleState, got ChaseState —— 因为没处理 EventPlayerLost 在 ChaseState 中的降级逻辑。
- 每个
State的Handle必须明确回答：这个事件我是否能处理？不能处理就返回原状态或错误，别静默忽略 - 写测试时，刻意构造「非法事件序列」：如连续两次
EventAttack、在DeadState上发EventMove，验证是否 panic 或返回合理状态 - 别 mock 状态切换本身；而是用真实
State实例，只 mock 它依赖的外部 service（如Pathfinder.FindPath） - 状态机主结构（如
AIBehavior）的测试重点是：事件输入 → 状态输出 →Context变更，三者是否原子一致
状态模式真正的复杂点不在结构，而在你能否清晰定义“什么算一个状态”“什么算一次合法切换”。游戏 AI 里，一个状态往往对应一组互斥的行为约束，而不是一段代码块。漏掉这点，再工整的接口也压不住逻辑熵增。
