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="2025-06-15T10:20:33Z"

避免 recover 后继续执行危险逻辑

recover 只是“捕获”，不代表错误已解决。恢复后不应继续使用可能处于不一致状态的对象（如已部分关闭的文件、损坏的 struct 字段等）。

• 最佳实践：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) })