Go中panic用于处理严重错误，通过defer+recover捕获并记录日志可防止程序崩溃。关键做法包括：recover必须在defer中调用，结合debug.Stack()获取完整调用栈，便于定位问题；在Web服务中可通过中间件统一捕获panic，如Gin的recovery机制，记录请求上下文并返回500错误；生产环境应集成zap、Sentry等工具，记录时间、goroutine ID、trace id等信息，确保顶层goroutine均被保护，且recover后不继续执行原逻辑，测试环境可禁用recover以快速暴露问题。
Go语言中，panic 是一种运行时异常机制，用于处理程序无法继续执行的严重错误。虽然Go推荐使用返回错误的方式处理常规异常，但在某些场景下 panic 仍不可避免。合理地记录 panic 日志并追踪调用栈，对线上服务的故障排查至关重要。
捕获 Panic 并记录日志
通过 defer + recover 可以在函数退出时捕获 panic，防止程序崩溃，同时记录详细信息。
基本模式如下：
func safeHandler() {
defer func() {
if r := recover(); r != nil {
log.Printf("panic caught: %v\n", r)
log.Printf("stack trace: %s", string(debug.Stack()))
}
}()
// 可能触发 panic 的代码
panic("something went wrong")
}
关键点：
立即学习“go语言免费学习笔记（深入）”；
- recover 必须在 defer 函数中调用才有效
- log 打印 panic 值和堆栈信息有助于定位问题
- debug.Stack() 返回完整的调用栈快照
获取详细的调用栈信息
标准库 runtime/debug 提供了 Stack 和 PrintStack 方法，可用于输出完整的 goroutine 调用栈。
建议在 recover 后使用 debug.Stack() 获取字符串形式的堆栈，便于写入日志系统。
示例：
stack := debug.Stack()
log.Printf("Panic recovered: %s\nStack:\n%s", r, stack)
该堆栈包含每一层函数调用的文件名、行号和函数名，是异常追踪的核心依据。
全局 panic 捕获中间件（适用于 Web 服务）
在 HTTP 服务中，可在中间件层面统一捕获 panic，避免单个请求导致服务中断。
例如 Gin 框架中的 recovery 中间件实现思路：
func RecoveryMiddleware() gin.HandlerFunc {
return func(c *gin.Context) {
defer func() {
if err := recover(); err != nil {
log.Printf("Panic in request: %s %s, error: %v", c.Request.Method, c.Request.URL.Path, err)
log.Printf("Stack: %s", string(debug.Stack()))
c.AbortWithStatus(http.StatusInternalServerError)
}
}()
c.Next()
}
}
这样即使某个 handler 发生 panic，也能返回 500 错误而非断开连接，同时保留日志。
生产环境建议
实际项目中应结合日志系统（如 zap、logrus）和监控平台（如 Sentry、ELK）进行 panic 上报。
关键实践包括：
- 所有顶层 goroutine 都应包裹 defer-recover
- panic 日志需包含时间、goroutine ID、请求上下文（如 trace id）
- 避免在 recover 后继续执行原逻辑，应安全退出或返回错误
- 测试环境下可禁用 recover 以便快速发现问题
基本上就这些。panic 不可避免，但只要做好捕获和记录，就能快速定位和修复问题。
