17370845950

状态模式通过接口+结构体组合在Go中实现，定义统一状态接口并由各具体状态实现，上下文委托行为并受控切换状态，避免条件判断与循环引用。

状态模式通过将对象的行为封装到独立的状态类中，让对象在不同状态下表现出不同行为，避免大量条件判断。Golang虽无继承和抽象类，但可通过接口 + 结构体组合 + 依赖注入优雅实现。

定义状态接口与具体状态实现

核心是声明一个统一的状态接口，每个具体状态（如Pending、Approved、Rejected）实现该接口：

• 接口方法应覆盖所有需随状态变化的行为，例如Handle()、CanEdit()、Next()
• 每个状态结构体不保存业务数据，只专注自身逻辑；状态切换由上下文或当前状态自行决定
• 避免在状态内部直接修改上下文字段，而是通过返回新状态或调用上下文提供的状态变更方法

构建上下文结构体并持有当前状态

上下文（如Order或Workflow）持有一个状态接口字段，并提供委托方法：

• 初始化时注入初始状态，例如order := &Order{state: NewPendingState()}
• 所有对外行为（如order.Submit()）实际委托给state.Handle(order)
• 状态变更不暴露state字段，而是通过order.TransitionTo(newState)等受控方法

状态切换：显式转移 vs 隐式返回

有两种主流方式驱动状态流转：

• 显式转移：上下文提供TransitionTo(s State)方法，由调用方（如业务逻辑）决定何时切状态，适合流程可控、需审计的场景
• 隐式返回：状态方法（如Handle()）返回next State，上下文自动更新，代码更紧凑，但状态路径不易追踪
• 建议初学者用显式方式，后期可封装为链式调用（如order.Approve().Notify()）

避免常见陷阱

Go 实现状态模式易踩的坑：

• 不要让状态结构体持有上下文指针形成循环引用——改用函数参数传入所需数据或最小接口
• 状态不应直接修改上下文私有字段；如需更新，通过上下文公开的SetXXX()方法或事件通知
• 测试每个状态行为时，用接口隔离依赖，对状态本身做单元测试，无需启动整个上下文
• 若状态数量多、转换规则复杂，可辅以状态图（如用go-graph生成）或配置化跳转表