recover后只看到panic值看不到堆栈，是因为recover()仅返回panic参数而不捕获调用栈；需配合debug.PrintStack()或runtime/debug.Stack()手动获取当前goroutine堆栈。
recover后为什么只看到panic值，看不到堆栈？
因为 recover() 默认只返回 panic 时传入的任意值（比如 error 或字符串），它本身不捕获调用栈。Go 的运行时在 panic 发生时才生成完整堆栈，但一旦被 recover() 拦截，这个堆栈就“丢失”了——除非你主动抓取。
用 debug.PrintStack() 打印当前 goroutine 堆栈
debug.PrintStack() 会把当前 goroutine 的完整调用栈输出到 os.Stderr，适合调试阶段快速定位 panic 来源。但它和 recover() 没有绑定关系，必须在 panic 后、recover() 调用后的同一 goroutine 中执行，且不能跨 defer 层级。
常见写法：
defer func() {
if r := recover(); r != nil {
fmt.Println("panic recovered:", r)
debug.PrintStack() // ← 这里能打出 panic 发生点及所有调用帧
}
}()
注意：debug.PrintStack() 不带返回值，无法存为字符串；它输出的是「当前执行位置」的堆栈，不是 panic 发生点的——但因为在 defer 中触发，通常就是 panic 后立刻执行，所以实际效果接近。
立即学习“go语言免费学习笔记（深入）”；
用 runtime/debug.Stack() 获取可处理的堆栈字符串
如果需要把堆栈转成 string 记录日志、上报或格式化，必须用 runtime/debug.Stack()。它返回 []byte，可直接转 string，也支持指定最大字节数防爆。
实操要点：
-
runtime/debug.Stack()返回的是「当前 goroutine 当前执行点」的堆栈，不是 panic 点——但配合recover()的 defer 使用，基本等价 - 别漏掉
import "runtime/debug" - 生产环境慎用大 buffer（默认 4KB），可传参限制长度：
debug.Stack(4096) - 若 panic 发生在子 goroutine，主 goroutine 的
debug.Stack()拿不到它的堆栈——这是设计使然，不是 bug
示例：
defer func() {
if r := recover(); r != nil {
stack := string(debug.Stack())
log.Printf("panic: %v\n%s", r, stack)
}
}()
想精确还原 panic 位置？得靠 panic value 本身带堆栈
标准库的 error 类型不会自动附带堆栈，但你可以用第三方包（如 github.com/pkg/errors 或 Go 1.13+ 的 fmt.Errorf("%w", err) + errors.WithStack() 风格）让 error 携带上下文。不过更直接的做法是：在 panic 前手动封装堆栈。
例如：
func safePanic(v interface{}) {
pc, file, line, _ := runtime.Caller(1)
fn := runtime.FuncForPC(pc)
panic(fmt.Sprintf("%v\n at %s:%d\n in %s", v, file, line, fn.Name()))
}
这样 recover() 拿到的值本身就含位置信息，再补上 debug.Stack() 就更完整。
真正容易被忽略的是：recover 必须在 panic 触发的同一 goroutine 中生效；goroutine 泄漏、defer 失效、或 recover 放错位置（比如在另一个函数里没 defer），都会导致堆栈“消失”。不是工具不行，是执行流断了。
