State接口方法必须用指针接收器，因Context中若以值类型存储接口会导致状态变更丢失；应统一用指针实现并由Context主动SetState，避免闭包捕获共享数据。
State 接口定义为什么必须是值接收器？
Go 里实现状态模式，State 通常定义为接口，比如 type State interface { Handle(*Context) }。但实际写的时候，如果所有具体状态类型（如 IdleState、RunningState）的方法用指针接收器，而 Context 里存的是值类型字段（如 state State），就可能意外丢失状态变更——因为赋值时复制的是接口底层值的副本，不是指针。
实操建议：
- 统一用指针接收器实现
State方法，且Context.state字段声明为*State或直接存具体指针（如*IdleState），避免接口装箱导致的拷贝陷阱 - 不要在
Handle内部直接修改接收器字段来“切换状态”，而是由Context主动调用SetState；否则容易绕过状态流转逻辑 - 如果状态需要共享数据，优先通过
Context传参，而不是在State实现里闭包捕获外部变量——后者会让测试和复用变得脆弱
如何避免状态流转时的空指针 panic？
常见错误现象：nil pointer dereference 在调用 ctx.state.Handle(ctx) 时爆发，尤其在初始化或异常重置后忘记设初态。
使用场景：服务启动、错误恢复、单元测试 setup 阶段
立即学习“go语言免费学习笔记（深入）”；
实操建议：
- 在
Context构造函数里强制设置初始状态，例如&Context{state: &IdleState{}}，不接受零值 - 在
Handle方法入口加防御判断：if s == nil { log.Panic("state is nil") }，比让 panic 发生在深层调用里更容易定位 - 测试时显式覆盖所有状态跳转路径，特别检查 “A → B → A” 这类环形流转是否会导致状态被置为
nil
goroutine 安全的状态切换怎么做？
当多个 goroutine 并发调用 Context.Handle() 或外部触发 Context.SetState()，状态字段可能被同时读写，引发竞态。
性能影响：加 sync.Mutex 最直接，但会串行化所有状态操作；若状态切换极频繁，要考虑用 atomic.Value 存储指针，前提是状态对象本身不可变（即每次切换都 new 新实例）
实操建议：
- 优先用
sync.RWMutex：读多写少场景下，Handle只读状态，SetState写，能提升并发吞吐 - 避免在
Handle内部做耗时操作（如 HTTP 调用、数据库查询），否则锁持有时间过长，放大阻塞风险 - 如果业务允许最终一致性，可把状态切换改为 channel 通信（如
stateCh <- newState），由单个 goroutine 顺序处理，解耦状态更新与执行
为什么不用 switch + 字符串状态名代替 State 接口？
看起来更轻量：switch ctx.StateName { case "idle": ... case "running": ... }。但它在复杂流程中很快失控。
容易踩的坑：
- 状态合法性无编译检查——拼错
"idie"不报错，运行时才失效 - 每个
case块重复访问ctx字段，无法封装共用逻辑（比如日志、指标上报） - 新增状态要改所有 switch，违反开闭原则；而接口实现只需加新类型，不碰旧代码
- 无法对特定状态做定制方法（如
RunningState.Pause()），只能堆 if 判断
真正复杂的状态机（比如订单生命周期、协议状态机），接口+结构体组合的扩展性和可测性远胜字符串分支。简单两三个状态倒可以先用 switch 快速验证逻辑，但一旦分支超过四条，就该重构了。
状态模式的麻烦点不在写法，而在“谁负责决定下一个状态”。这个决策逻辑很容易散落在各处，最后变成没人敢动的隐式规则。把它收拢到每个 State 的 Handle 方法里，或者单独抽成 TransitionRule，比靠注释维护更可靠。
