状态模式通过接口定义状态行为，结构体实现具体状态，上下文委托调用，实现订单等对象的状态流转控制，提升可维护性与扩展性。
在Go语言中，状态模式是一种行为设计模式，适用于对象的行为随着其状态改变而改变的场景。通过接口实现状态转换，可以让状态变更更加清晰、可维护，尤其适合管理复杂的业务状态流转，比如订单状态、任务流程等。
定义状态接口与上下文
状态模式的核心是定义一个状态接口，所有具体状态实现该接口。上下文（如订单、任务）持有一个状态接口的引用，并通过委托调用当前状态的方法。
示例：订单状态管理
假设订单有“待支付”、“已支付”、“已发货”、“已完成”几种状态，状态之间有明确的流转规则。
立即学习“go语言免费学习笔记（深入）”；
先定义状态接口：
type OrderState interface {
Pay(order *Order) error
Ship(order *Order) error
Complete(order *Order) error
}上下文结构体持有当前状态：
type Order struct {
State OrderState
// 其他字段：ID, Amount等
}实现具体状态
每个状态实现接口，并在方法中控制合法的状态转移。状态之间通过修改订单的 State 字段完成切换。
例如，“待支付”状态：
type PendingState struct{}
func (s *PendingState) Pay(order *Order) error {
order.State = &PaidState{}
return nil
}
func (s *PendingState) Ship(order *Order) error {
return fmt.Errorf("cannot ship: order not paid yet")
}
func (s *PendingState) Complete(order *Order) error {
return fmt.Errorf("cannot complete: order not shipped yet")
}“已支付”状态：
type PaidState struct{}
func (s *PaidState) Pay(order *Order) error {
return fmt.Errorf("order already paid")
}
func (s *PaidState) Ship(order *Order) error {
order.State = &ShippedState{}
return nil
}
func (s *PaidState) Complete(order *Order) error {
return fmt.Errorf("cannot complete: order not shipped yet")
}类似地实现 ShippedState 和 CompletedState。
状态转换的控制与安全
通过接口和具体实现，非法状态转移在逻辑层被阻止。比如不能对已支付订单再次支付，或未发货就完成。
可以在上下文中封装操作，使调用更自然：
func (o *Order) Pay() error {
return o.State.Pay(o)
}
func (o *Order) Ship() error {
return o.State.Ship(o)
}
func (o *Order) Complete() error {
return o.State.Complete(o)
}使用方式：
order := &Order{State: &PendingState{}}
order.Pay() // 状态变为 PaidState
order.Ship() // 状态变为 ShippedState
order.Complete() // 状态变为 CompletedState优势与适用场景
这种模式将状态逻辑分散到独立的结构体中，避免了大量 if-else 或 switch 判断，提升可读性和扩展性。
适合：
- 状态多且转换规则复杂
- 不同状态下行为差异大
- 需要在运行时动态改变对象行为
注意点：
- 状态切换由具体状态实现控制，确保上下文不直接修改状态
- 状态对象可设计为单例，避免重复创建
- 可结合事件机制或钩子函数处理状态变更的副作用（如发通知）
基本上就这些。用接口抽象状态，结构体实现行为，上下文委托执行，是Go中实现状态模式的自然方式。
