状态机中panic常见于底层操作越界或非法，recover必须在每个状态处理函数内defer绑定，不可外置；recover后需显式处理流转（如转error状态），并确保状态一致性。
状态机中 panic 的常见触发点
状态机流转时发生 panic，通常不是因为“状态跳转逻辑出错”，而是底层操作越界或非法：比如访问 nil 指针、切片越界、map 写入未初始化、类型断言失败、或主动 panic("invalid transition from A to Z")。这些错误一旦发生，会立刻中断当前状态处理函数，导致状态机卡死或 goroutine 崩溃。
recover 必须绑定在状态处理函数的 defer 中
不能在状态机外层（如主循环）统一加一个 recover 就指望它捕获所有状态流转 panic —— 因为 recover 只对当前 goroutine 且当前函数调用栈中发生的 panic 有效。状态机每步执行通常封装在独立函数里，必须在每个可能 panic 的状态处理函数内部加 defer + recover。
- 错误写法：
main函数里写一次defer recover()→ 它只捕获main自身的 panic，不覆盖handleStateA里的 panic - 正确写法：每个状态处理函数开头就加
defer func() { if r := recover(); r != nil { ... } }() - 若状态机用闭包或方法调用（如
s.handle("START")），recover必须放在该方法内部，不能放在调用方
recover 后如何安全继续状态机流转
recover 本身不会让程序“回到 panic 那行继续执行”，它只是退出 panic 状态、恢复 goroutine 执行流。所以你必须显式决定后续动作：是重试当前状态？降级到 error 状态？还是终止该次流转？
- 不要直接
return后就丢弃状态上下文 —— 例如状态机依赖ctx *StateContext，panic 后ctx可能已处于不一致状态，需重置或标记为失效 - 推荐返回一个明确的错误信号：
return ErrInvalidStateTransition，由上层判断是否重试或兜底 - 如果状态机支持“错误状态”（如
STATE_ERROR），可在recover后主动调用s.transitionTo(STATE_ERROR)，而不是继续原路径 - 避免在
recover块里再调用可能 panic 的函数（比如又去查数据库），否则会二次崩溃且无法捕获
goroutine 分离状态流转时 recover 容易漏掉
如果状态机把每步流转扔进新 goroutine（如 go s.handleNext()），那主 goroutine 的 recover 完全无效 —— 子 goroutine 的 panic 只能由它自己内部的 defer + recover 捕获。
- 常见陷阱：用
safeGo包装状态处理函数，但忘了在包装体内部放recover - 正确模式：
func (s *StateMachine) safeHandle(state string) { go func() { defer func() { if r := recover(); r != nil { s.logger.Error("state panic", "state", state, "err", r) s.transitionTo(STATE_ERROR) } }() s.doHandle(state) }() } - 注意：子 goroutine 中
recover捕获后，无法通知主 goroutine “我挂了”，需靠 channel 或回调传递结果
recover 自动修复。golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
