state 接口应设计为无状态、事件驱动：定义 canhandle(Event) bool 和 handle(ctx, event, data) Error 方法，配合统一 event 类型与迁移校验表，避免方法爆炸与非法跳转。
State 接口怎么设计才不容易崩
go 没有抽象类，State 模式靠接口驱动，但直接定义 State 接口容易掉进“方法爆炸”坑——比如每个状态都要实现 HandleEventA、HandleEventB……结果新增一个事件就得改所有状态类型。
更务实的做法是让状态只关心自己能响应的事件，用「事件分发 + 方法存在性检查」代替穷举接口：
- 定义统一的
Event类型（比如String或自定义枚举） - 每个状态类型实现
CanHandle(event Event) bool和Handle(ctx context.Context, event Event, data Interface{}) error - 状态机在
transition时先调用CanHandle，再调用Handle，避免 panic 或静默忽略
这样加新事件只需改判断逻辑，不碰已有状态代码。
FSM 的状态迁移必须带上下文校验
很多人把状态切换写成 fsm.currentState = newState 就完事，结果出现非法跳转（比如从 Submitted 直接到 Archived），或并发下状态错乱。
立即学习“go语言免费学习笔记（深入）”；
真正稳的做法是：所有迁移走 Transition(event Event, data interface{}) error 方法，并在里面做三件事：
- 检查当前状态是否允许触发该
event（查预设的合法转移表，比如 map[State]map[Event][]State） - 调用当前状态的
CanHandle(event)做二次确认 - 用
sync.Mutex或sync/atomic控制状态变量写入（尤其当Handle可能异步时）
漏掉校验，上线后问题往往出现在边缘流程，比如重试、超时回调、人工干预入口。
工作流里状态要存外部数据，别塞进 State 实例
常见错误是把订单 ID、用户 ID、时间戳全塞进某个 PendingState 结构体里，导致状态对象变重、无法复用、GC 压力大。
State 类型应该无状态（stateless）——它只描述“行为”，不持有“实例数据”：
- 把业务数据（如
orderID,userID）放在 FSM 实例或传入Handle的data参数里 - State 类型只保留纯函数逻辑，比如
func (s *ApprovedState) Handle(...) { ... } - 如果真需要缓存，用外部
map[OrderID]time.Time等独立结构，和状态机解耦
否则一不小心就写出“每个订单都 new 一堆 State 对象”的内存泄漏模式。
测试 State 切换逻辑时，别只测单步
单元测试常只验证 fsm.Transition("approve") → ApprovedState，但真实工作流是链式的：提交→审核→发布→归档。单步通过不代表路径正确。
关键测试点得覆盖：
- 非法路径拦截：比如
Submit → Archive必须返回非 nil error - 中间态副作用：从
Pending切到Approved是否发了通知？是否更新了 DB 字段？这些得用 interface mock - 重复事件幂等：连续两次
"approve"，第二次应返回 error 或静默忽略，不能重复发消息
最容易被忽略的是「事件参数透传」——比如审批操作带 approverID，这个值得完整流经整个 Handle 链，而不是在某一层丢了。