Go 中协程 panic 不会传播至主 goroutine，须在每个 goroutine 内部用 defer+recover 捕获并结构化记录日志，recover 后仅清理退出，不可继续执行或盲目重试。
在 Go 中，协程（goroutine）中发生的 panic 不会自动传播到主 goroutine，也不会终止整个程序，但若不主动捕获，会导致该 goroutine 悄悄退出，错误被丢弃，难以排查。要保障主程序稳定运行，关键是在每个可能 panic 的 goroutine 内部做 独立 recover，并配合结构化日志记录。
在 goroutine 内部用 defer + recover 捕获 panic
recover 只在 defer 函数中有效，且仅对当前 goroutine 的 panic 生效。必须在启动 goroutine 的函数内部（而非外部）设置 defer recover 逻辑。
- 错误写法：在主函数里 defer recover —— 对子 goroutine 无效
- 正确写法：每个 goroutine 启动时，立即包裹一层带 defer recover 的匿名函数
统一 panic 日志格式，包含上下文信息
单纯打印 panic 错误不够，需记录 goroutine ID（可选）、时间、调用栈、业务标识（如任务 ID、用户 ID），便于追踪。
- 使用 runtime/debug.Stack() 获取完整堆栈，避免只输出 panic message
- 建议用 zap、zerolog 等结构化日志库，将 panic 作为 error level 日志记录
- 示例字段：level="error", event="goroutine_panic", stack="...", task_id="upload_123", time="2024-06-15T10:20:33Z"
避免 recover 后继续执行危险逻辑
recover 只是“捕获”，不代表错误已解决。恢复后不应继续使用可能处于不一致状态的对象（如已部分关闭的文件、损坏的 struct 字段等）。
立即学习“go语言免费学习笔记（深入）”；
- 最佳实践：recover 后仅做清理和日志，然后安全退出该 goroutine
- 不要尝试“重试”或“续跑”，除非你明确知道状态可恢复（极少见）
- 若需重试，应由上层调度器（如 worker pool 或定时任务）重新派发新 goroutine
对长期运行的 goroutine 做兜底防护
例如 http handler、消息消费者、定时任务等，应在入口处强制加 recover。可封装为通用装饰器：
func WithRecover(f func()) {
go func() {
defer func() {
if r := recover(); r != nil {
logger.Error("goroutine panicked",
zap.Any("recovered", r),
zap.String("stack", string(debug.Stack())))
}
}()
f()
}()
}
调用时：WithRecover(func() { handleMQMessage(msg) })
