如何使用Golang捕获并记录协程panic_保证主程序稳定运行

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) })

# go # golang # 栈 # red # 封装 # Error # 堆 # Struct # Event # 对象 # http # 重试 # 结构化 # 是在 # 主程序 # 不代表 # 不应 # 可选 # 只在 # 应在 # 而非

返回目录在线咨询

上一篇：建站服务器选购指南及硬件配置方案推荐
下一篇：基于Vue如何封装分页组件

您的项目需求