必须为每个goroutine单独设置defer recover，因主函数的recover无法捕获子协程panic；recover后不可复用损坏状态，应新建干净上下文并安全退出。
recover 必须写在每个 goroutine 的 defer 里
流式处理通常启多个 goroutine 消费 channel，比如从 Kafka、WebSocket 或 HTTP/2 stream 拉数据。一旦某个协程 panic（如解码失败、空指针访问、map 并发读写），主线程不会感知，但该协程会静默退出——后续数据就卡住或丢失。你不能指望主函数加一个 defer 就能 catch 所有子协程的 panic。
必须为每个长期运行的 worker 单独包一层防护：
go func() { defer func() { if r := recover(); r != nil { log.Printf("worker panic: %v", r) } }(); processStream(ch) }()- 别用
defer recover()——这是常见错误，它会在注册时立刻执行，返回nil - 如果 worker 内部还启动子协程（比如异步写 DB），那些子协程也得各自加
defer+recover，无法继承外层保护
panic 后不能“重置状态”，只能新建干净上下文
流式处理中常遇到：某条消息触发 panic("json: cannot unmarshal string into Go struct")，你想“跳过这条、继续下一条”。但 recover() 成功后，当前函数栈已展开，局部变量、map、slice、sync.Mutex 等状态可能已损坏。直接复用原有结构体或缓存对象极大概率二次 panic。
- 正确做法是：在
recover块里只做记录和退出，不要调用resetState()这类业务函数 - 把状态初始化逻辑提到循环顶部，每次处理新消息前都新建干净实例：
msg := new(Message); err := json.Unmarshal(data, msg) - 避免在 defer 中修改共享状态（如
counter++），因为 panic 可能发生在任意位置，计数可能漏或重复
recover 后如何安全地“继续消费”
很多流式代码写成 for data := range ch { ... }，但 panic 发生在循环体内时，for 本身不会中断——只要 recover 在 defer 里且没提前 return，循环会继续。这看似符合“重置后继续”的需求，但要注意边界：
诊断并恢复通过 SSH 隧道连接的 OpenClaw 节点。用于解决配对必需错误、隧道冲突、远程端点错误以及 SSH 目标配置错误等问题。
- 确保
recover后不依赖任何被破坏的局部变量（比如 panic 前刚append到一半的buf） - 如果用了
bufio.Reader或自定义 buffer，panic 可能让 reader 内部 offset 错乱；建议每次 panic 后close当前连接或重新new一个 reader - 对 HTTP 流或 WebSocket，recover 后应主动
conn.Close()或发送 error frame，而不是静默续传——客户端可能已断连
为什么 defer + recover 不适合做“全局流控中间件”
有人试图封装一个 SafeStream(fn func([]byte) error)，统一加 recover。这在简单场景可行，但流式处理的真实复杂度会让它失效：
- fn 内部若启动 goroutine 并 panic，
SafeStream的 defer 完全无感 - fn 若持有长生命周期资源（如 DB 连接池、TLS session），recover 后无法保证这些资源仍可用
- 类型断言风险：panic 值可能是
string、error、甚至自定义 struct，r.(error).Error()会再次 panic，必须先判空再 switch 类型
真正健壮的流式恢复，靠的是隔离（per-worker defer）、不可变输入（每次新分配 buffer）、以及明确的失败退出路径，不是靠 recover 后强行续跑。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
