Go中状态模式通过接口组合实现，上下文持状态接口并委托调用；状态切换应由当前状态方法返回新状态，由上下文统一赋值，确保业务规则不被绕过。
状态模式在 Go 中不是靠继承，而是靠接口组合
Go 没有类和继承，所以不能照搬传统状态模式（比如 Java 里让每个状态实现 State 接口、上下文持有一个可变的 state 引用）。真正的 Go 风格是：定义一个核心状态接口，让具体状态类型实现它；上下文结构体持有该接口值，并通过方法委托调用当前状态的行为。
常见错误是试图用 interface{} 或反射来回切换状态，结果失去类型安全和可读性。正确做法是让状态类型彼此解耦，只依赖抽象接口，不互相引用。
- 状态接口应只暴露业务行为方法（如
HandleEventA()、CanTransitionToX()），不暴露内部字段或 setter - 上下文结构体（如
OrderProcessor）的字段应为currentState State，而非具体类型 - 状态切换必须由当前状态决定是否允许，而不是由外部强行赋值——否则会绕过业务规则
如何避免状态跃迁失控？用返回值约束转移路径
直接在 State 方法里修改上下文的 currentState 字段，会导致状态变更逻辑分散、难以追踪。更可控的方式是：每个状态方法返回下一个状态接口值（或 nil 表示不转移），由上下文统一处理赋值。
这能强制开发者显式声明“这个事件之后应该进入什么状态”，也方便加日志、审计或拒绝非法跳转。
立即学习“go语言免费学习笔记（深入）”；
func (s *PendingState) Confirm() State {
if !s.canConfirm() {
return s // 保持原状态
}
log.Println("order confirmed")
return &ConfirmedState{OrderID: s.OrderID}
}
// 上下文统一处理
func (p *OrderProcessor) Confirm() {
next := p.currentState.Confirm()
if next != nil {
p.currentState = next
}
}
状态类型要不要带业务数据？取决于生命周期和共享粒度
如果状态只读且不保存中间结果（比如纯决策型状态 ValidatingState），可以设计成无字段的单例变量：var ValidatingState = &validatingState{}。这样节省内存，也避免误改状态内部。
但如果状态需要维护临时数据（如审批流中记录已通过的节点、支付状态中缓存 token），就必须让每个实例携带独立数据。这时要注意：不要把整个业务实体（如 *Order）塞进状态里，而应只传必要字段或使用组合方式复用。
- 推荐用组合：状态类型内嵌一个轻量结构体（如
orderID string,attemptCount int），而不是指针引用原始业务对象 - 避免在多个状态类型之间共享可变字段——容易引发竞态，尤其在并发调用时
- 如果状态需访问数据库或外部服务，把 client 作为依赖注入进状态构造函数，而非硬编码
测试状态流转时，别 mock 接口，直接实例化具体状态
写单元测试时，很多人想 mock State 接口来验证行为。但 Go 的状态模式本质是“不同结构体实现同一接口”，最自然的测试方式是：直接创建具体状态实例，调用其方法，检查返回值和副作用（如日志、新状态类型）。
例如测试 PendingState.Confirm() 是否返回 *ConfirmedState，就 assert 返回值的动态类型：
func TestPendingState_Confirm(t *testing.T) {
s := &PendingState{OrderID: "ORD-123"}
next := s.Confirm()
_, ok := next.(*ConfirmedState)
if !ok {
t.Fatal("expected *ConfirmedState, got", reflect.TypeOf(next))
}
}
真正难测的是跨状态的长流程（比如从 Pending → Confirmed → Shipped），这时应重点覆盖边界条件：重复提交、非法事件顺序、超时自动降级等。这些逻辑往往藏在状态实现内部，而不是接口定义里。
状态模式本身不解决并发安全，也不自动处理持久化。这两块得靠你在上下文或状态方法里显式加锁、事务或事件落库——它们不在模式范畴内，但实际项目里几乎必然要面对。
