当一段业务逻辑里出现了大量的if-else或者switch分支，而且每个分支的判断条件都是同一个状态变量时，代码往往就开始变得难以维护。状态模式（State Pattern）正是为了解决这类问题而生的：它把每一种状态及其对应的行为封装到独立的类型中，状态切换时行为也随之改变，调用方无需关心内部细节。本文将以Golang为载体，从原理到实战，完整讲解状态模式的实现方式。
状态模式的核心思想与结构
状态模式属于行为型设计模式，它的关键在于"用组合替代条件分支"。传统写法中，一个对象的某个方法内部会根据当前状态执行不同逻辑，状态越多，方法越长，改一个状态可能影响整个方法。状态模式则把"状态"抽象成一个接口，每种具体状态实现这个接口，Context对象持有一个当前状态的引用，把操作委托给状态对象处理。
状态模式通常包含三个角色：一是Context（上下文），对外提供接口并维护当前状态；二是State接口，声明所有状态下可能执行的操作；三是ConcreteState（具体状态），实现接口并定义在该状态下的行为，同时负责触发状态流转。这样做的最大好处是新增状态只需要增加一个结构体并实现接口，完全不需要改动已有状态的核心逻辑，符合开闭原则。
需要指出的是，Golang没有继承和抽象类的概念，但这并不妨碍实现状态模式。Go的隐式接口机制非常契合这一模式：只要具体状态类型实现了接口定义的全部方法，就可以直接赋值给接口变量，代码非常自然。
用Golang实现一个完整的状态模式示例
下面以最常见的订单状态流转为例。订单有三种状态：待支付、已支付、已完成。用户在不同状态下执行"支付"和"发货"操作，行为和结果都不同。
首先定义State接口和Context结构体：
// State 状态接口，声明所有操作
type State interface {
Pay(order *Order)
Ship(order *Order)
}
// Order 上下文，持有当前状态
type Order struct {
orderId string
state State
}
func NewOrder(id string) *Order {
return &Order{
orderId: id,
state: &UnpaidState{},
}
}
func (o *Order) SetState(s State) {
o.state = s
}
func (o *Order) Pay() {
o.state.Pay(o)
}
func (o *Order) Ship() {
o.state.Ship(o)
}接着实现三个具体状态。注意每个状态的行为是独立的，状态流转由状态对象自己调用SetState完成：
// UnpaidState 待支付状态
type UnpaidState struct{}
func (s *UnpaidState) Pay(order *Order) {
fmt.Println("订单", order.orderId, "支付成功")
order.SetState(&PaidState{}) // 流转到已支付
}
func (s *UnpaidState) Ship(order *Order) {
fmt.Println("支付前无法发货")
}
// PaidState 已支付状态
type PaidState struct{}
func (s *PaidState) Pay(order *Order) {
fmt.Println("订单已支付，请勿重复支付")
}
func (s *PaidState) Ship(order *Order) {
fmt.Println("订单", order.orderId, "发货成功")
order.SetState(&CompletedState{}) // 流转到已完成
}
// CompletedState 已完成状态
type CompletedState struct{}
func (s *CompletedState) Pay(order *Order) {
fmt.Println("订单已完成，无法支付")
}
func (s *CompletedState) Ship(order *Order) {
fmt.Println("订单已完成，无法发货")
}调用方代码非常干净，完全不需要感知状态判断：
func main() {
order := NewOrder("10001")
order.Pay() // 支付成功
order.Ship() // 发货成功
order.Pay() // 订单已完成，无法支付
}运行后输出依次是支付成功、发货成功、订单已完成无法支付。可以看到，main函数里没有任何条件判断，所有的分支逻辑被分散到了三个状态结构体中。如果后续要增加"已取消"状态，只需新增一个结构体并修改相关状态的流转目标即可，影响范围极小。
状态模式与switch分支写法的对比分析
同样的订单逻辑，用switch实现的版本大致是这样的：
func (o *Order) Pay() {
switch o.status {
case StatusUnpaid:
o.status = StatusPaid
fmt.Println("支付成功")
case StatusPaid:
fmt.Println("请勿重复支付")
case StatusCompleted:
fmt.Println("无法支付")
}
}在状态只有两三种时，switch写法简单直接，反而更容易阅读，这时候强行上状态模式属于过度设计。但当状态数量增长到五六个以上，且每个状态下都有多种操作时，switch会出现在每一个方法内部，任何一次状态机调整都要同时修改多个方法，遗漏一处就产生难以排查的bug。
两者的核心差异可以从三个维度衡量。第一是可扩展性：状态模式新增状态只需加文件，switch需要改所有涉及的方法。第二是可测试性：每个具体状态都是独立结构体，可以单独做单元测试，switch版本只能整体测试。第三是状态流转的清晰度：状态模式把流转逻辑写在状态内部，流转路径一目了然；switch版本的状态变更散落各处，容易形成隐晦的流转规则。
还有一个折中方案值得了解：如果状态流转规则非常规整（比如单向线性流转），可以用一个转移表配合枚举来实现，代码量介于两者之间。不过在流转规则复杂、不同状态行为差异大的时候，状态模式仍然是首选。
Golang实现状态模式的注意事项与进阶技巧
第一个要注意的点是并发安全。Context中持有的state字段会被多个goroutine读写时，必须用sync.Mutex保护，或者在流转时使用原子操作。特别是支付这种涉及资金的状态，重复流转会造成资损，务必保证状态变更的原子性。
第二个点是状态对象是否携带数据。上例中状态结构体都是空结构体，可以复用单例减少内存分配。但如果状态需要记录进入时间、重试次数之类的临时数据，就不能简单复用，每次流转都应该创建新实例，避免数据被多个Context共享污染。
// 带数据的状态，每次流转必须新建实例
type RetryingState struct {
retryCount int
enterTime time.Time
}第三个点是避免循环依赖。状态接口的方法签名中引用了Context类型，而Context又持有State接口，这本身没问题；但如果具体状态反过来又引用Context的具体方法，容易把边界搅乱。建议状态对象只通过接口方法签名中传入的Context指针操作，不要在内部长期持有Context引用。
最后一个进阶技巧是结合函数类型实现轻量级状态机。对于简单场景，可以定义type StateFunc func(ctx *Context)，让函数自身既是状态又是行为，流转时直接赋值新函数。这种写法省去了接口和结构体的样板代码，非常适合状态行为非常简单的场景，但在状态需要携带逻辑较多时就不如接口方案清晰了。
总结一下，状态模式的本质是把状态驱动的行为变化从条件分支中解耦出来。在Golang中借助接口的隐式实现，这一模式的落地成本很低。判断是否该用它的标准很简单：当你的状态数量在三个以上，且每个状态下多个操作行为各不相同时，就值得重构为状态模式；反之，简单的两态切换直接写if语句反而更好维护。
Golang状态模式State Pattern行为设计模式修改时间：2026-09-14 13:09:01