在 Go 中捕获 panic 并输出完整调用栈，需在 defer 函数中用 recover() 捕获，并配合 debug.PrintStack() 或 runtime/debug.Stack() 获取堆栈；仅打印 panic 值会丢失调用路径，生产环境应同时记录 panic 值、堆栈、时间戳等。
在 Go 中捕获 panic 并输出完整调用栈，关键在于使用 recover() 配合 debug.PrintStack() 或 runtime/debug.Stack()。直接用 log.Fatal 或 fmt.Println 打印 panic 错误本身只能看到错误消息，看不到函数调用路径——而堆栈信息对定位问题至关重要。
使用 recover 捕获 panic 并打印堆栈
panic 只能在 defer 函数中被 recover 捕获，且必须在 panic 发生的 goroutine 内部进行。常见写法是在入口函数（如 main 或 http handler）中加一层 defer：
- 在可能 panic 的代码外层用
defer声明一个匿名函数 - 在该函数内调用
recover()，判断是否发生了 panic - 若捕获到值，立即调用
debug.PrintStack()输出当前 goroutine 的完整堆栈
示例：
func main() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic recovered: %v", r)
debug.PrintStack() // 输出到 os.Stderr
}
}()
// 可能 panic 的代码，比如：panic("something went wrong")
panic("test panic")
}
获取堆栈字符串用于自定义日志或上报
如果需要把堆栈转成字符串（比如写入文件、发到监控系统），应使用 runtime/debug.Stack()，它返回 []byte，可直接转为 string：
立即学习“go语言免费学习笔记（深入）”；
-
debug.Stack()返回当前 goroutine 的堆栈快照，不带额外输出 - 建议配合
log.Printf或结构化日志库（如 zap、logrus）记录 - 注意：该函数在运行时开销较小，但频繁调用仍需评估性能影响
示例：
defer func() {
if r := recover(); r != nil {
stack := debug.Stack()
log.Printf("panic: %v\nstack:\n%s", r, stack)
}
}()
避免只打印 panic 错误而忽略调用链
常见误区是只记录 r（即 panic 的参数），例如 log.Println(r)。这会丢失所有调用上下文，无法知道 panic 是在哪一层函数触发的。
- panic 的值（如
string、error）只是“什么错了”，不是“怎么错的” - 堆栈信息才体现“从 main → handler → service → db.Query 出错”这样的路径
- 生产环境建议同时记录 panic 值 + 完整堆栈 + 时间戳 + goroutine ID（可选）
在 HTTP 服务中统一处理 panic
Web 服务中，每个 handler 都可能 panic。可在中间件中统一 recover，避免每个 handler 都写 defer：
- 写一个
recoverMiddleware，包装 handler 函数 - 在 middleware 的 defer 中 recover 并记录堆栈
- 恢复后返回 500，并可选地屏蔽敏感信息（如开发环境显示堆栈，生产环境仅记录）
示例中间件片段：
func recoverMiddleware(next http.Handler) http.Handler {
return http.HandlerFunc(func(w http.ResponseWriter, r *http.Request) {
defer func() {
if err := recover(); err != nil {
log.Printf("[PANIC] %s %s: %v", r.Method, r.URL.Path, err)
log.Printf("Stack:\n%s", debug.Stack())
http.Error(w, "Internal Server Error", http.StatusInternalServerError)
}
}()
next.ServeHTTP(w, r)
})
}
