推荐用 interface{} 定义状态行为契约、各具体状态用独立 struct 实现，以保障切换安全、可测试、无副作用；Context 通过私有字段+SetState() 原子控制状态，内置迁移规则表校验合法性。
状态机核心结构用 interface{} 还是 struct 实现？
Go 没有继承，也不支持抽象类，所以「状态模式」必须靠组合 + 接口来模拟。关键不是「模仿 Java 写法」，而是让状态切换安全、可测试、无副作用。
推荐用 interface{} 定义状态行为契约，每个具体状态用独立 struct 实现，避免共享字段导致状态污染：
type State interface {
Handle(ctx *Context) error
Name() string
}
type IdleState struct{}
func (s *IdleState) Handle(ctx *Context) error {
if ctx.Input == "start" {
ctx.SetState(&RunningState{})
return nil
}
return fmt.Errorf("idle: unexpected input %q", ctx.Input)
}
func (s *IdleState) Name() string { return "idle" }
常见错误：把所有状态逻辑塞进一个大 struct 里，用 switch state 分支处理——这本质是「状态枚举 + 条件分支」，不是状态模式，后期难维护、难单元测试。
Context 如何安全持有并切换 State？
状态切换必须原子、线程安全（尤其在 goroutine 场景下），且不能让旧状态继续被调用。别直接暴露 state 字段。
立即学习“go语言免费学习笔记（深入）”；
- 用私有字段 +
SetState()方法控制赋值，内部做非空校验和日志记录 - 在
Context.Handle()中只调用当前状态的Handle()，不透传或缓存状态引用 - 如果涉及并发，
SetState()应加sync.Mutex或用atomic.Value（适用于只读状态对象）
type Context struct {
mu sync.RWMutex
state State
Input string
}
func (c *Context) SetState(s State) {
c.mu.Lock()
defer c.mu.Unlock()
if s == nil {
panic("state cannot be nil")
}
c.state = s
}
func (c *Context) Handle() error {
c.mu.RLock()
s := c.state
c.mu.RUnlock()
if s == nil {
return errors.New("no state set")
}
return s.Handle(c)
}
如何避免状态迁移环路与非法跳转？
真实业务中，不是所有状态都能任意跳转（比如「error」状态可能只允许回到「idle」，不能直通「running」）。硬编码 SetState(&XState{}) 很容易漏掉约束。
建议在 Context 中内置迁移规则表，用 map 显式声明合法转移：
var validTransitions = map[string][]string{
"idle": {"running", "error"},
"running": {"paused", "stopped", "error"},
"paused": {"running", "stopped", "error"},
"error": {"idle"},
}
然后在 SetState() 中校验：
func (c *Context) SetState(s State) {
c.mu.Lock()
defer c.mu.Unlock()
from := c.state.Name()
to := s.Name()
allowed := false
for _, t := range validTransitions[from] {
if t == to {
allowed = true
break
}
}
if !allowed {
panic(fmt.Sprintf("illegal transition: %s → %s", from, to))
}
c.state = s
}
这个检查在开发/测试阶段能快速暴露设计漏洞；上线后可降级为日志告警，避免 panic 影响主流程。
何时该用状态机，而非简单 switch 或配置驱动？
状态机不是银弹。以下情况才值得引入：
- 状态数量 ≥ 4，且迁移逻辑随状态组合变化（如「暂停中收到中断信号」和「运行中收到中断信号」行为不同）
- 需要外部观察状态变更（比如通过 channel 广播
StateEvent{From:"idle", To:"running"}） - 状态行为需动态加载（如插件化状态实现，从文件或网络加载新
State类型）
如果只是「开/关/错误」三态，且迁移固定，用 switch ctx.State { case Idle: ... } 更轻量。强行套状态模式只会增加间接层和初始化成本。
最容易被忽略的一点：状态对象本身不应持有业务数据（如用户 ID、任务 ID），这些应全由 Context 承载。否则状态复用、测试隔离、goroutine 安全都会出问题。
