状态模式通过接口+结构体组合在Go中实现，定义统一状态接口并由各具体状态实现，上下文委托行为并受控切换状态，避免条件判断与循环引用。
状态模式通过将对象的行为封装到独立的状态类中，让对象在不同状态下表现出不同行为，避免大量条件判断。Golang虽无继承和抽象类，但可通过接口 + 结构体组合 + 依赖注入优雅实现。
定义状态接口与具体状态实现
核心是声明一个统一的状态接口，每个具体状态（如Pending、Approved、Rejected）实现该接口：
- 接口方法应覆盖所有需随状态变化的行为，例如Handle()、CanEdit()、Next()
- 每个状态结构体不保存业务数据，只专注自身逻辑；状态切换由上下文或当前状态自行决定
- 避免在状态内部直接修改上下文字段，而是通过返回新状态或调用上下文提供的状态变更方法
构建上下文结构体并持有当前状态
上下文（如Order或Workflow）持有一个状态接口字段，并提供委托方法：
- 初始化时注入初始状态，例如order := &Order{state: NewPendingState()}
- 所有对外行为（如order.Submit()）实际委托给state.Handle(order)
- 状态变更不暴露state字段，而是通过order.TransitionTo(newState)等受控方法
状态切换：显式转移 vs 隐式返回
有两种主流方式驱动状态流转：
立即学习“go语言免费学习笔记（深入）”；
- 显式转移：上下文提供TransitionTo(s State)方法，由调用方（如业务逻辑）决定何时切状态，适合流程可控、需审计的场景
- 隐式返回：状态方法（如Handle()）返回next State，上下文自动更新，代码更紧凑，但状态路径不易追踪
- 建议初学者用显式方式，后期可封装为链式调用（如order.Approve().Notify()）
避免常见陷阱
Go 实现状态模式易踩的坑：
- 不要让状态结构体持有上下文指针形成循环引用——改用函数参数传入所需数据或最小接口
- 状态不应直接修改上下文私有字段；如需更新，通过上下文公开的SetXXX()方法或事件通知
- 测试每个状态行为时，用接口隔离依赖，对状态本身做单元测试，无需启动整个上下文
- 若状态数量多、转换规则复杂，可辅以状态图（如用go-graph生成）或配置化跳转表
