Golang协程panic捕获与记录技巧

在 Go 中，协程（goroutine）内的 panic 不会自动传播或终止主程序，若未主动捕获，将导致错误静默丢失、排查困难；因此必须在每个可能出错的 goroutine 内部通过 defer + recover 进行独立捕获，并配合结构化日志（如 zap 或 zerolog）记录时间、堆栈、业务标识等关键上下文，同时严格遵循“recover 后仅清理并退出”的原则——绝不继续执行潜在不一致的逻辑或盲目重试，必要时由上层调度器重新发起任务；对 HTTP 处理、消息消费等长期运行场景，更应通过通用 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 字段等）。

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

今天关于《Golang协程panic捕获与记录技巧》的内容就介绍到这里了，是不是学起来一目了然！想要了解更多关于的内容请关注golang学习网公众号！