Go panic 发生后怎么用 defer 记录调用上下文

Go 服务出现 panic 时，最实用的记录方式不是在外层函数直接调用 recover()，而是在目标函数入口注册一个 deferred function：先取出 panic 值，再调用 debug.Stack() 保存当前 goroutine 的调用上下文。这样日志里同时有“发生了什么”和“从哪里发生”，请求也可以在恢复后返回明确的 500 结果。

defer 里做什么，才能同时拿到 panic 和堆栈

panic 沿当前 goroutine 的调用栈向上展开，展开期间执行已经注册的 defer。只有 defer 调用的函数真正运行时，recover() 才能拿到 panic 值；把它写成外层函数的普通表达式，或者放到另一个 goroutine，都不在同一条恢复链上。

入口函数可以先保存请求编号，再把记录动作放入匿名 deferred function。debug.Stack() 应该在这里立即读取，避免只记录一行“panic: xxx”而丢掉业务函数、文件名和行号。

func withPanicLog(requestID string, next func()) {
    defer func() {
        if value := recover(); value != nil {
            // 在恢复点保存当前 goroutine 的完整堆栈，便于定位文件和行号。
            stack := debug.Stack()
            log.Printf("panic request_id=%s value=%v\\n%s", requestID, value, stack)
        }
    }()

    next()
}

这个函数只负责记录和恢复，不把 panic 值伪装成普通业务成功。生产入口还应在恢复后设置失败状态或返回错误；如果需要让调用方决定响应内容，可以把记录器改成返回 panicked bool，由上层统一写 500。

把请求字段和恢复动作放在同一个日志事件里

堆栈解决“代码在哪里”，请求 ID、路由和用户操作解决“哪一次请求”。两者分开写会增加排查时的拼接成本。实践中可以让恢复函数接收结构化字段，记录时固定事件名，避免把 panic 文本当作日志级别或状态码。

记录完后要决定边界：HTTP handler 可以写统一错误响应，定时任务可以让任务失败并触发重试。不要在恢复器里偷偷返回“成功”，否则监控看到的是正常请求，真正的故障却只藏在日志中。

为什么 recover 只能影响当前 goroutine

Go 的 panic 和 defer 都绑定当前 goroutine 的调用栈。主 goroutine 为 worker 启动的函数设置 defer，并不能捕获 worker 内部的 panic；worker 必须在自己的入口设置恢复逻辑。若不恢复，panic 会继续向该 goroutine 的栈顶展开，最终可能让整个程序退出。

func startWorker(jobID string, work func()) {
    go func() {
        defer func() {
            if value := recover(); value != nil {
                // worker 自己记录堆栈，并把失败状态交给任务系统处理。
                log.Printf("worker panic job_id=%s value=%v\\n%s", jobID, value, debug.Stack())
            }
        }()
        work()
    }()
}

这不表示所有异常都该用 panic。参数不合法、依赖超时、资源不存在等可预期情况应继续返回 error；recover 更适合作为进程边界或 goroutine 边界的最后保护，并留下足够上下文。

接入前检查这几个恢复边界

第一，确认 defer 注册在可能 panic 的调用之前；第二，确认 recover() 位于 deferred function 内，而不是 defer 的参数表达式中；第三，确认日志写入不会再次 panic，并控制堆栈长度和敏感字段；第四，恢复后明确响应、任务状态或连接关闭动作。这样做的目标是保住诊断信息和服务边界，不是把 panic 当成正常控制流。

相关问题

直接调用 recover() 为什么拿不到 panic？

因为它没有在 defer 调用的函数体内执行。将它放进匿名函数或具名 deferred function，才能处在 panic 展开的恢复点。

debug.Stack() 和 runtime.Stack() 有什么区别？

debug.Stack() 面向当前 goroutine 并返回格式化结果；需要自定义缓冲区或收集其他 goroutine 时，再考虑 runtime.Stack()。

recover 之后还要返回 error 吗？

通常要。recover 只阻止 panic 继续展开，不代表本次请求或任务成功，调用方仍应获得失败状态并执行清理。