Go 错误处理 panic recover 如何保留堆栈

Go 里想让服务在一次请求 panic 后继续处理后续请求，通常要在函数退出前用 defer 调用 recover。但只保存 panic 值不够：真正排查问题还需要触发现场的调用堆栈。实用写法是，在同一个 deferred 函数里先调用 recover() 判断是否正在展开，再调用 debug.Stack() 保存堆栈。

核心顺序：defer 注册恢复函数，recover() 取出 panic 值，runtime/debug.Stack() 立即复制当前 goroutine 的堆栈；记录后再把它转换为业务层可以处理的错误。

recover 为什么必须放在 defer 里

recover 只能在 panic 正沿着当前 goroutine 的调用栈展开时生效。把它直接写在普通业务语句里，或者从另一个 goroutine 调用，都不能捕获原来的 panic。恢复边界应当靠近你愿意兜底的函数，例如 HTTP handler、任务入口或消息消费入口。

package main

import "fmt"

func runTask() (err error) {
	defer func() {
		// recover 只能在 deferred 函数中读取当前 goroutine 正在展开的 panic。
		if value := recover(); value != nil {
			err = fmt.Errorf("task panic: %v", value)
		}
	}()

	panic("bad payload")
}

这里的具名返回值让 deferred 函数可以把 panic 转成 error。这解决了“程序继续返回”的问题，但错误里还没有文件名、函数和调用行，下一步要把堆栈一起保存。

在 recover 的现场保存 Stack

runtime/debug.Stack() 返回当前 goroutine 的堆栈字节。它应该和 recover() 写在同一个 deferred 函数中，并在拿到 panic 值后立即复制或格式化；不要等函数继续做复杂逻辑之后再取，否则堆栈不再清晰地表达出错位置。

package main

import (
	"fmt"
	"runtime/debug"
)

func runTask() (err error) {
	defer func() {
		// 先取出 panic，再抓取当前调用现场，便于日志关联根因。
		if value := recover(); value != nil {
			stack := debug.Stack()
			err = fmt.Errorf("task panic: %v\n%s", value, stack)
		}
	}()

	panic("bad payload")
}

记录系统可以把 value 作为摘要，把 stack 作为详细字段。生产环境还应给请求 ID、任务 ID或消息键加上上下文，但不要把口令、令牌等敏感值拼进 panic 文本。

统一返回时要避免把 panic 悄悄吞掉

恢复的目标是隔离一次异常，不是把程序当作“没有出错”。建议保留原始堆栈并返回一个带上下文的错误，让上层决定记录、重试或丢弃。对于不可恢复的程序不变量破坏，也可以记录堆栈后继续 panic，而不是强行返回成功。

func guardedHandle(input string) (err error) {
	defer func() {
		// 统一包装异常；上层仍能根据 err 决定告警或重试。
		if value := recover(); value != nil {
			stack := debug.Stack()
			err = fmt.Errorf("handle %q panicked: %v\n%s", input, value, stack)
		}
	}()

	return parseAndSave(input)
}

这里的 input 只适合放经过脱敏的标识。若返回值会被 HTTP 层直接展示，最好再用一个稳定的外部错误码替代完整堆栈，堆栈只写入受控日志。

goroutine、nil panic 与使用边界

每个 goroutine 都有自己的 panic 链路。主 goroutine 的 recover 接不到子 goroutine 的 panic，因此并发任务的入口也要单独包一层 defer。另一个细节是 panic(nil) 在不同 Go 版本和运行时设置下可能让“用返回值是否为 nil 判断”产生误解；如果需要覆盖所有 panic 形态，应结合项目支持的 Go 版本确认语义，并保证恢复策略不会把正常路径混入异常路径。

速记如下：

相关问题

只调用 debug.Stack 不调用 recover 可以吗？

可以得到当前调用堆栈，但不能阻止正在展开的 panic。需要隔离 panic 时仍要在 deferred 函数中调用 recover。

recover 后还能拿到原始 panic 类型吗？

可以，recover 返回的是触发 panic 时传入的值，先保留它再格式化，必要时用类型断言区分错误类型。

为什么主 goroutine 的 recover 接不到子 goroutine？

panic 和 recover 都绑定当前 goroutine 的调用栈，必须在创建任务的 goroutine 内部设置恢复边界。

官方资料：https://pkg.go.dev/builtin#recover、https://pkg.go.dev/runtime/debug#Stack、https://go.dev/blog/defer-panic-and-recover