Go 实现状态模式的核心是将状态抽象为接口，由具体状态类型实现行为逻辑，上下文仅委托调用并管理状态切换，确保职责分离、避免 if-else 冗余。
用 Go 实现状态模式，核心是把“状态”抽成独立类型，让对象的行为随状态变化而自然切换，而不是堆一堆 if-else 或 switch。
定义状态接口与具体状态
先设计一个统一的状态接口，声明该状态下对象能做什么；每个具体状态实现这个接口，封装对应行为逻辑。
- 接口方法通常对应对象的关键行为（如 Handle、Process、Click 等），返回值可选是否需要转移状态
- 每个具体状态结构体只关心自己该做什么，不依赖其他状态，也无需知道上下文细节
- 例如：订单系统中可能有 Pending、Confirmed、Shipped 三种状态，各自实现不同的 Confirm() 或 Ship() 响应
创建上下文（Context）管理当前状态
上下文结构体持有当前状态的接口引用，并提供触发行为的方法。它不判断逻辑，只把调用委托给当前状态。
- 状态切换由具体状态决定：比如 Pending.Confirm() 可以返回 &Confirmed{}，上下文接收后更新自身 state 字段
- 推荐用指针接收状态接口，避免复制；上下文的 SetState 方法应接受接口类型，保持解耦
- 初始化时显式设置初始状态，比如 ctx.state = &Pending{}
避免状态流转失控
Go 没有枚举或 sealed class，容易误切到非法状态。可通过以下方式增强健壮性：
- 状态类型使用未导出字段（如 type pending struct{}），只导出变量（var Pending State = &pending{}），限制外部构造
- 在状态方法内部做前置校验（如 Ship() 在 Pending 状态下直接 panic 或返回 error）
- 必要时在上下文中加状态变更日志或钩子（如 onStateChange），便于调试和审计
简化写法：用函数值代替小状态
如果状态逻辑极简（比如只有 1–2 行处理 + 单一跳转），也可用 func() State 替代完整结构体，减少样板代码。
- 例如：type State func() State；每个状态是一个闭包，执行后返回下一个状态函数
- 适合原型验证或状态极少的场景，但不利于单元测试和扩展，生产环境仍推荐接口 + 结构体
基本上就这些。Go 里实现状态模式不复杂，关键在克制——别让状态自己去操作上下文，也别让上下文去猜状态意图。职责分明，切换自然。
