状态机核心用struct+interface{}实现，Context持State接口，各状态独立实现Handle方法且不持有Context引用，切换需显式调用SetState，禁止返回状态值自动跳转，所有流转点可grep追踪，避免枚举判态，并发时仅SetState加锁。
状态机核心结构用 struct + interface{} 就够了
Go 没有类继承，也不推荐用嵌套 struct 模拟“子类化”，状态模式的关键是把「当前行为」委托给独立的状态对象。最简实现只需要一个上下文 Context 和一组实现统一接口的状态类型：
type State interface {
Handle(ctx *Context)
}
type Context struct {
state State
}
func (c *Context) SetState(s State) {
c.state = s
}
func (c *Context) Request() {
c.state.Handle(c)
}
每个具体状态（如 IdleState、RunningState）只实现 Handle 方法，不持有 Context 引用——避免循环依赖，也利于单元测试。
状态切换必须显式调用 SetState，不能靠方法返回值自动跳转
常见误区是让 Handle 方法返回下一个状态，然后在 Request 里自动赋值。这会掩盖状态流转逻辑，导致调试困难。正确做法是：状态内部决定何时切换，并直接调用 c.SetState(...)。
-
Handle方法内可调用ctx.SetState(&RunningState{})，但不能返回新状态 - 所有状态切换点必须可追踪——grep
SetState就能定位全部流转路径 - 若需条件跳转（如超时回退），把判断逻辑放在状态内部，而不是外部调度器
避免用字符串或整数枚举管理状态，直接用指针比较更安全
有人喜欢定义 const Idle = iota; Running，再用 switch ctx.stateID 分支处理。这破坏了状态对象的封装性，也失去多态优势。Go 中更稳妥的方式是：
立即学习“go语言免费学习笔记（深入）”；
- 用
if ctx.state == &idleState{}判断（需确保单例或用指针地址比较） - 或为每个状态类型添加
Type() string方法，仅用于日志/调试，不用于控制流 - 禁止在
Handle外部通过字段读写状态数据——所有状态相关字段应只在对应状态 struct 内维护
并发场景下必须加锁，但锁粒度要小到只包住 SetState
如果多个 goroutine 可能同时触发状态变更（比如定时器 + 用户命令），Context.state 是竞态点。不要整个 Request() 加锁，只需保护状态赋值本身：
type Context struct {
mu sync.RWMutex
state State
}
func (c *Context) SetState(s State) {
c.mu.Lock()
c.state = s
c.mu.Unlock()
}
func (c *Context) Request() {
c.mu.RLock()
s := c.state
c.mu.RUnlock()
s.Handle(c)
}
注意：Handle 方法内部若需读写 Context 的其他字段，应由该方法自行加锁——状态对象自己最清楚哪些字段归它管。
状态机真正的复杂点不在结构，而在于状态间的数据传递和生命周期管理。比如退出 RunningState 前是否要清理资源？这些逻辑必须落在具体状态的 Handle 里，而不是塞进 SetState 的钩子函数中。
