Go 的 switch 本身不维护状态，仅作分支判断；必须显式更新状态变量，避免依赖 fallthrough；复杂状态机应使用查表法、状态方法或专用库。
用 switch 实现状态转移时，为什么状态变量没更新？
Go 的 switch 本身不维护状态，它只是分支判断工具。常见错误是把状态变更逻辑写在 case 里却忘了赋值给状态变量，或者误以为 case 执行完自动“跳转”到下一个状态。
- 必须显式更新状态变量，比如
state = StateRunning - 别依赖
fallthrough模拟状态流转——它只向下穿透一次，且容易漏掉break导致意外执行 - 如果状态转移逻辑复杂（比如需校验输入、触发副作用），建议把每个
case内容抽成独立函数，避免switch块过长
状态机需要响应事件，switch 怎么配合事件循环？
纯 switch 是同步一次性判断，真要响应连续事件（如网络包、用户操作），得套一层循环，并在每次迭代中接收新事件再做状态切换。
- 典型结构：外层
for循环 + 内层switch state判断当前行为，再嵌套switch event处理输入 - 事件类型建议用自定义
enum（即具名常量），比如EventStart、EventTimeout，别直接用字符串或整数魔法值 - 注意阻塞问题：如果事件来源是
chan，记得用select配合default避免死等；若用fmt.Scanln这类同步 IO，整个状态机就卡住了
多个状态共用同一事件，怎么避免 switch 嵌套过深？
当不同状态对同一事件有不同反应（比如 EventStop 在 Running 状态下暂停，在 Paused 状态下直接退出），硬写成 switch state { case Running: switch event { ... } case Paused: ... } 很快就难以维护。
- 推荐用二维映射：定义
type transitionMap map[State]map[Event]State，查表决定下一状态 - 或更清晰的做法：为每个状态实现一个方法，如
(s *RunningState) Handle(e Event) (State, error)，让状态自己决定如何响应 - 不要为了“看起来简洁”强行压缩逻辑——比如把所有状态转移写进一个超大
switch，一旦加个新状态就得通读全表
为什么 switch 看起来像状态机，但实际不适合复杂状态管理？
Go 的 switch 是编译期静态分支，没有状态生命周期管理能力（比如进入/退出钩子、超时重置、并发安全控制），也不支持状态继承或组合。
立即学习“go语言免费学习笔记（深入）”；
- 简单流程（3–5 个状态，无并发、无持久化）用
switch完全够用，代码直白易读 - 一旦涉及定时器（
time.AfterFunc）、goroutine 协作、或需保存中间数据（如重试次数、缓冲区），就得上专用库（如go-statemachine）或手写带字段的结构体 - 最容易被忽略的一点：测试困难——
switch块里的逻辑分散在各case中，很难单独 mock 某个状态的行为，而面向对象或函数式状态机更容易单元隔离
