状态机的核心是显式转移逻辑而非结构体嵌套：必须通过Transition函数触发状态变更并返回新状态，各状态类型实现统一State接口（含Enter/Exit/HandleEvent），且HandleEvent须用指针接收器以保状态数据一致性，禁止阻塞操作，测试应基于事件流断言状态类型。
状态机的核心不是结构体嵌套，而是转移逻辑的显式表达
Go 语言没有原生状态机语法，硬套类继承或接口组合反而会让状态流转变得隐晦。真正关键的是：每个状态变更必须通过明确的 Transition 函数触发，且该函数要返回新状态（或错误），不能靠直接赋值 sm.state = newState 绕过校验。
常见错误是把状态存成 int 或 string，然后用一堆 if/else 判断当前状态能否响应某个事件——这本质上仍是条件分支，不是状态机。正确做法是让每个状态类型自己实现 HandleEvent() 方法，把“能响应什么、响应后变成什么”封装进状态内部。
- 状态类型应为导出的具名类型（如
type IdleState struct{}），而非匿名结构体 - 所有状态需统一实现同一接口（如
State），包含Enter()、Exit()和HandleEvent() - 状态切换必须由上下文（state machine 实例）调用
currentState.HandleEvent(e)后，用返回的新状态替换当前状态
用指针接收器实现状态切换时的副作用控制
状态对象本身可能需要维护临时数据（比如重试次数、超时计时器），如果用值接收器实现 HandleEvent()，每次调用都会复制整个状态，导致计数器重置、定时器丢失。必须用指针接收器，确保状态内字段的修改能被后续调用感知。
但要注意：指针接收器不等于允许外部随意修改状态字段。所有字段应设为非导出（小写开头），仅通过方法暴露可控行为。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 错误写法：
func (s IdleState) HandleEvent(e Event) State→ 状态内计数器无法累积 - 正确写法：
func (s *IdleState) HandleEvent(e Event) State→ 可安全更新s.attemptCount++ - 若某状态无需保存中间状态（如纯转发型状态），可用值接收器，但需在文档中明确说明
避免在 HandleEvent 中阻塞或执行耗时操作
状态机实例通常运行在单个 goroutine 中（尤其是用于协议解析、设备控制等场景），一旦 HandleEvent() 里调用了 time.Sleep、http.Do 或未带超时的 chan 操作，整个状态机就卡死了。
正确做法是把耗时逻辑移出状态处理流程，改用事件驱动：状态响应事件后，启动 goroutine 执行任务，并在完成时发送新事件（如 TaskCompleted）回状态机。
- 禁止在
HandleEvent()内部调用time.Sleep(5 * time.Second) - 允许在
HandleEvent()中启动 goroutine：go s.doAsyncWork(e, sm.PostEvent) -
sm.PostEvent是状态机提供的线程安全事件投递方法，确保新事件最终进入主循环
测试状态机的关键是隔离事件序列与断言最终状态
单元测试不要 mock 状态类型，而应构造完整事件流，验证每一步的状态变化是否符合预期。重点检查边界情况：非法事件是否被拒绝、重复事件是否被忽略、超时事件是否触发降级路径。
示例测试片段：
func TestStateMachine_TransitionOnValidEvent(t *testing.T) {
sm := NewStateMachine()
sm.PostEvent(StartEvent{})
if _, ok := sm.CurrentState().(*RunningState); !ok {
t.Fatal("expected RunningState after StartEvent")
}
sm.PostEvent(PauseEvent{})
if _, ok := sm.CurrentState().(*PausedState); !ok {
t.Fatal("expected PausedState after PauseEvent")
}
}- 测试中不调用私有方法，只通过
PostEvent()和CurrentState()交互 - 用类型断言（
sm.CurrentState().(*RunningState)）确认状态类型，比比较字符串更可靠 - 对非法事件（如
PauseEvent在IdleState下）应单独测试是否返回错误，且状态不变
状态机最难的部分从来不是定义状态和事件，而是当业务规则变复杂时，如何让新增状态不破坏已有转移路径的可读性——建议把每个状态的合法事件列表写在对应类型的注释里，而不是藏在某个中央配置表中。
