消费goroutine必须用defer+recover包裹，否则panic会导致goroutine静默退出、消息积压、服务卡死；recover需在goroutine最外层使用，检查返回值并记录日志、跳过失败消息，不可用于事务回滚或状态恢复。
消费 goroutine 必须用 defer + recover 包裹
不加 recover 的消费 goroutine 一旦 panic，整个 goroutine 会静默退出，后续消息不再被处理，队列积压，服务看似正常实则已“卡死”。recover 不是可选项，是保活底线。
关键点在于：必须在启动消费的 goroutine 内部、最外层用 defer 注册 recover，且不能漏掉 recover() 的返回值检查——只调用不接收返回值等于没写。
- 错误写法：
defer recover()或defer func() { recover() }()（返回值被丢弃） - 正确写法：
defer func() { if r := recover(); r != nil { /* 处理 */ } }() - recover 只对当前 goroutine 有效，跨 goroutine panic 无法捕获
panic 后要记录日志 + 标记失败消息，不能吞掉
recover 拦住 panic 只是第一步。如果只打印一句 "panic recovered" 就继续循环，你根本不知道哪条消息、在哪一行、因为什么出错，下次还会重蹈覆辙。
真实场景中，panic 往往来自 JSON 解析失败、空指针解引用、第三方库断言崩溃等，这些都和具体消息强相关。必须把 r 值、原始消息 ID、topic、时间戳一并记入日志，最好额外落盘或写入 fallback DB。
- 别用
fmt.Printf，用结构化日志（如log.With或 zap）带上下文字段 - 避免在 recover 块里做耗时操作（如 HTTP 请求、DB 写入），否则阻塞消费循环
- 记录后应显式跳过当前消息（
continue），不要试图“修复后重试”——panic 表明状态已不可信
别在 recover 里重试或恢复资源
recover 能终止栈展开、让 goroutine 继续运行，但它不能回滚已发生的副作用。比如 panic 发生前已向 DB 插入半条记录、已发了一半 HTTP 请求、已修改了全局 map，这些都不会自动撤销。
试图在 recover 块里“手动清理”极易出错，尤其涉及锁、channel、文件句柄等资源时。Go 的 recover 设计本意就是“止损+逃生”，不是“事务回滚”。
- 资源清理应在 defer 中独立完成（如
defer conn.Close()），与 recover 分离 - 不要在 recover 块里调用
close(chan)或mutex.Unlock()—— 你无法确定它们是否已被调用过 - 若业务逻辑本身需要幂等/重试，应在消费主流程中设计，而非依赖 panic 后的补救
注意 recover 对 goroutine 生命周期的误导
recover 成功后，goroutine 会继续执行 defer 函数之后的代码，看起来“活过来了”。但实际它可能已处于不一致状态：局部变量损坏、channel 缓冲区残留、context 已 cancel、甚至 runtime 内部状态异常（如 panic 来自 map 并发读写）。
所以，recover 后最安全的做法是：记录、跳过、继续下一条。不要尝试复用当前 goroutine 做复杂恢复，更不要让它长期存活并累积状态。
- 高可靠场景建议：recover 后直接
return退出该 goroutine，由上层（如 supervisor）拉起新 goroutine - 永远检查
recover()返回值是否为nil—— 在非 panic 场景下调用它会返回nil，误判会导致逻辑错乱 - 别把 recover 当 error 处理用；常规错误（如网络超时、序列化失败）该走
error分支就走，不该触发 panic
recover 不是银弹，它只解决“goroutine 因 panic 消失”这一个问题。真正防卡死，靠的是清晰的错误边界、结构化日志、消息可追溯、以及消费逻辑本身的健壮性。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
