State接口应仅定义当前状态合法行为，避免预设所有动作；状态转移由上下文统一调度并加锁；初始化需依赖注入且校验非nil；状态对象应轻量无状态或明确管理生命周期。
State 接口怎么设计才不踩坑
Go 没有继承，状态模式靠接口组合实现，State 接口不能暴露太多方法，否则每个状态都要实现一堆空方法。常见错误是把所有业务动作（比如 InsertCoin、EjectCoin、TurnCrank）全塞进接口，结果新增一个状态就要补 10 个空实现。
正确做法是只定义「当前状态能响应什么」——也就是该状态下的合法行为，其他非法操作统一返回错误或 panic。比如售货机空闲时只允许 InsertCoin，那 IdleState 就只实现它，其余方法要么不实现（编译报错提醒你漏了），要么用 panic("illegal transition") 明确拒绝。
-
State接口只包含当前状态实际需要响应的方法，不要预设所有可能动作 - 让具体状态结构体只嵌入真正需要的接口（如
coinable、crankable），而不是大而全的State - 避免在接口里放
GetNextState这类逻辑，状态转移决策应由上下文（如VendingMachine）控制
状态转移为什么不能在 State 内部做
很多初学者会在 InsertCoin 方法里直接改 machine.currentState = &HasCoinState{}，这会导致两个问题：一是状态对象自己修改宿主，耦合过重；二是并发下容易出现竞态——比如两个 goroutine 同时调用 InsertCoin，可能一个刚判断完状态，另一个就已切换，导致逻辑错乱。
状态转移必须由持有状态的主体（如 VendingMachine）统一调度，且要用互斥锁保护 currentState 字段。转移前检查合法性（比如是否允许从当前状态转到目标状态），比事后 panic 更可控。
立即学习“go语言免费学习笔记（深入）”；
- 所有
State方法只返回「下一步该做什么」，例如func (s *IdleState) InsertCoin() (nextState State, err error) - 实际赋值
machine.currentState = nextState必须在VendingMachine的方法内完成，并加machine.mu.Lock() - 如果转移需异步（如网络请求后才切换），不要在
State方法里启 goroutine，而是返回 channel 或 callback，由外部协调
FSM 初始化和默认状态怎么设才安全
常见错误是把初始状态写成 currentState: &IdleState{}，但 IdleState 如果依赖外部资源（比如数据库连接、日志器），而初始化时这些还没准备好，就会 panic。更隐蔽的问题是：如果 IdleState 是零值结构体，而它的方法里用了未初始化的字段（比如 s.logger.Info），运行时直接 nil pointer dereference。
初始化必须确保所有状态对象的依赖都已注入。推荐用工厂函数或构造器显式传参，而不是裸字面量。
- 不要用结构体字面量直接初始化状态，改用带参数的构造函数，如
NewIdleState(logger *zap.Logger) - 在
VendingMachine的NewVendingMachine函数里完成所有状态的初始化，并校验必要字段非 nil - 启动时先设为
nil状态，再调用Reset()方法进入初始态，避免「半初始化」状态被误用
如何避免状态泄漏和内存占用失控
有些实现会为每次状态转移 new 一个新状态对象（比如 &SoldState{}），但如果状态频繁切换（如每秒上百次），GC 压力会明显上升。更麻烦的是，如果某个状态持有了长生命周期资源（如 *sql.Tx、http.Client），又没提供 Close() 或 Teardown() 方法，这些资源就永远卡在内存里。
状态对象应该轻量、无状态（stateless），或者明确管理生命周期。复杂资源交给 FSM 主体持有，状态只负责逻辑分支。
- 状态结构体不要包含大字段（如
[]byte、map[string]interface{}），这些数据放VendingMachine里共享 - 如果状态必须持有资源（如临时文件句柄），定义
Exit()方法，在切换前由 FSM 主动调用 - 考虑复用状态实例（如单例模式），只要它不保存 per-transition 数据，就完全安全
状态模式真正的难点不在「怎么写接口」，而在「谁负责决策转移」和「谁持有资源生命周期」。这两点模糊了，代码很快变成一连串 if-else 的马甲。Go 的简洁性反而会放大设计偏差——没有虚函数强制约束，更容易把状态逻辑散落在各处。
