Go通过接口+结构体组合实现轻量状态模式：定义State接口封装行为，Machine持State接口并加锁转发请求，状态切换需避免循环引用和阻塞操作，注重并发安全与资源清理。
Go 语言没有类和继承，状态模式不能照搬传统 OOP 的写法；但通过接口 + 结构体组合 + 方法集，完全可以实现等效、更轻量的状态切换逻辑。
用 interface 定义状态行为契约
状态模式的核心是把“不同状态下对同一请求的响应”抽成统一接口。在 Go 中，这必须是一个接口，比如：
type State interface {
Handle(ctx context.Context, req *Request) error
Name() string
}
所有具体状态（如 IdleState、RunningState）都实现该接口。注意两点：
- 避免在接口中暴露过多方法——只放真正随状态变化的行为，像
Enter()或Exit()属于生命周期钩子，应由上下文结构体统一调用，不放进State接口 - 接口方法参数尽量精简，优先传值或不可变结构（如
*Request），避免传入整个上下文对象导致状态实现强耦合
用嵌入结构体实现状态切换与委托
上下文（Context）不直接持有状态值，而是持有一个 State 接口变量，并把请求转发给当前状态：
立即学习“go语言免费学习笔记（深入）”；
type Machine struct {
mu sync.RWMutex
state State
}
func (m *Machine) Handle(ctx context.Context, req *Request) error {
m.mu.RLock()
defer m.mu.RUnlock()
return m.state.Handle(ctx, req)
}
状态切换发生在具体操作中，例如：
func (m *Machine) Start() {
m.mu.Lock()
defer m.mu.Unlock()
m.state = &RunningState{machine: m} // 注意：这里传回指针，避免循环引用或拷贝丢失
}
关键点：
- 不要让状态结构体直接持有上下文指针再反向调用方法（易引发循环引用或 goroutine 安全问题），推荐用回调函数或事件通道解耦
- 状态切换必须加锁——即使
state是接口类型，赋值本身不是原子操作，尤其在并发调用Handle()时可能读到中间态
避免在状态实现中做阻塞或长耗时操作
Go 的状态模式常用于网络服务、任务机、连接管理器等场景，而 Handle() 往往是被协程并发调用的入口。如果某个状态（如 ConnectingState）内部执行 net.Dial() 并同步等待，会卡住整个状态机。
正确做法是：
- 状态的
Handle()应快速返回，把耗时逻辑交给后台 goroutine 或异步任务队列 - 用 channel 或
sync.Once控制初始化类操作（如首次连接），避免重复 dial - 若需等待结果，状态应转入
PendingState，并在回调中触发machine.setState(NextState)
典型错误示例：ConnectingState.Handle 里直接 conn, err := net.Dial(...) —— 这会让所有后续请求排队等待这个 dial 完成。
测试状态流转时重点覆盖边界条件
状态模式真正的复杂度不在实现，而在流转逻辑是否健壮。测试时不能只测“Idle → Running → Stopped”，还要验证：
- 重复
Start()是否幂等（比如已在RunningState时再调用，是否 panic 或静默忽略） - 并发调用
Start()和Stop()是否导致状态错乱（常见于未加锁或锁粒度太粗） - 某个状态的
Handle()返回错误后，状态是否仍保持原状，还是意外跳转到了错误状态 - GC 是否能正常回收已退出的状态实例（尤其当状态持有闭包或 channel 时）
最容易被忽略的是：状态对象本身可能包含可变字段（如重试计数、超时定时器），这些字段在状态切换后是否被正确清理或重置——Go 没有析构函数，得靠显式 Reset() 或每次新建状态实例来规避。
