状态模式在go中通过接口+结构体组合+方法赋值实现，适用于生命周期明确、状态转换规则固定且行为随状态显著变化的对象；它避免了switch分支导致的开闭原则违背、状态转移逻辑分散、测试困难及并发安全问题。
状态模式在 Go 里不是靠继承和抽象类实现的，而是用接口 + 结构体组合 + 方法赋值来达成的；它适合管理有明确生命周期、状态间转换规则固定、且行为随状态显著变化的对象（比如订单、工作流节点、连接会话）。
为什么不用 switch 判断状态来写业务逻辑
直接在每个方法里 switch state 看起来简单，但很快会遇到问题：
- 新增状态要改所有涉及状态判断的方法，违反开闭原则
- 状态转移逻辑分散，容易漏掉校验（比如“已取消”不能转回“待支付”）
- 测试困难——同一方法在不同状态下行为不同，需要大量重复 setup
- 并发下如果状态字段没加锁或没用原子操作，
state可能被中间态污染
Go 中状态模式的核心结构：接口 + 委托 + 状态切换控制
关键不是“定义一堆状态类”，而是把「当前行为」委托给当前状态对象，并由状态对象决定能否切换到下一个状态：
- 定义
State接口，包含所有业务行为方法（如Pay()、Ship()、Cancel()） - 每个具体状态（如
pendingState、paidState）实现该接口，只处理自己允许的操作 - 主结构体（如
Order）持有state State字段，所有行为方法都转发给o.state.Xxx() - 状态切换不开放给外部直接赋值，而是通过状态对象自己的方法返回新状态（例如
pendingState.Pay()返回paidState{}），再由主结构体更新
这样能天然约束非法转移：如果 paidState.Cancel() 返回 cancelledState{}，而 paidState.Pay() 返回自身或 panic，逻辑就收口在状态内部。
立即学习“go语言免费学习笔记（深入）”；
实际项目中要注意的三个坑
很多团队落地时栽在这几个地方：
-
State接口方法如果需要访问主结构体字段（比如订单号、用户ID），别传整个结构体指针进去——会导致循环依赖；改用函数选项或通过闭包注入必要字段，或者让状态持有一个轻量Context结构体 - 状态对象本身应该是无状态的（即不保存字段），否则多个订单共用同一个状态实例会出错；每次切换都应构造新实例（如
return paidState{orderID: s.orderID}） - 并发安全不能只靠“状态切换是原子的”——
o.state = newState是原子的，但o.state.Pay()和赋值之间可能有其他 goroutine 干扰；真正安全的做法是在主结构体上加sync.RWMutex，读状态时加读锁，写状态时加写锁
一个极简但可运行的订单状态示例
以下代码去掉日志和错误处理，仅保留核心流转逻辑：
type State interface {
Pay(*Order) error
Cancel(*Order) error
}
type pendingState struct{}
func (p pendingState) Pay(o *Order) error {
o.state = paidState{}
return nil
}
func (p pendingState) Cancel(o *Order) error {
o.state = cancelledState{}
return nil
}
type paidState struct{}
func (p paidState) Pay(o *Order) error { return errors.New("already paid") }
func (p paidState) Cancel(o *Order) error {
o.state = cancelledState{}
return nil
}
type Order struct {
ID string
state State
}
func NewOrder() *Order {
return &Order{state: pendingState{}}
}
func (o *Order) Pay() error { return o.state.Pay(o) }
func (o *Order) Cancel() error { return o.state.Cancel(o) }
注意：真实项目中 State 实现体往往需要携带上下文（如用户权限、时间戳），这时建议用带字段的结构体 + 构造函数，而不是空结构体。
状态模式真正的复杂点不在定义，而在状态图收敛——当业务方不断提“能不能从 A 直接到 C？”“D 状态下允许重试三次”，状态转移矩阵就会迅速膨胀；这时候得配合 DSL 描述状态图，再自动生成状态类型，否则维护成本远高于收益。
