debug.printstack()可快速打印当前goroutine堆栈，不终止程序但无格式；Errors.withstack()保留原始错误堆栈，适合链式错误；runtime.caller()手动提取调用信息；pprof可查看所有goroutine全局堆栈。
用 debug.PrintStack() 快速打印当前 goroutine 堆栈
当程序 panic 前卡死、或想在某处主动查看调用链时，debug.PrintStack() 是最轻量的堆栈快照方式。它不依赖错误对象，直接输出到 os.Stderr，适合开发期临时埋点。
- 必须导入
"runtime/debug"包 - 只打印**当前 goroutine** 的堆栈，无法看到其他协程状态
- 不会终止程序，但输出无格式、无颜色，和日志混在一起时容易被忽略
- 示例：
import "runtime/debug" // ... fmt.Println("before crash") debug.PrintStack() fmt.Println("after stack")
用 errors.WithStack()（github.com/pkg/errors）保留原始堆栈
标准库 error 在多层包装时会丢失原始出错位置。github.com/pkg/errors 的 WithStack() 能在创建错误时捕获调用点，后续用 errors.PrintStack(err) 或 fmt.printf("%+v", err) 可展开完整路径。
- 注意：Go 1.13+ 原生
errors.Unwrap()和%w格式符已支持链式错误，但**不自动记录堆栈**；pkg/errors是目前最成熟的堆栈感知方案 - 不要对同一错误反复调用
WithStack()，会导致堆栈重复叠加 - 生产环境慎用——每次调用都触发 runtime.Caller，有轻微性能开销
- 示例：
import "github.com/pkg/errors" func readConfig() error { f, err := os.Open("config.yaml") if err != nil { return errors.WithStack(err) // ← 此处记录堆栈 } defer f.Close() return nil }
用 runtime.Caller() 手动提取调用信息
当需要自定义错误上下文（比如加 traceID、文件行号标记），runtime.Caller() 是底层可控的方式。它返回 PC、文件名、行号和是否在函数内，比全堆栈更轻量。
- 参数是「向上跳几帧」：0 是
Caller自身，1 是调用它的函数，通常传 2 或 3 获取业务代码位置 - 返回的
pc需用runtime.FuncForPC(pc).Name()解析函数名，但若函数被内联（inlined），可能返回空字符串 - 跨 package 调用时，确保目标函数未被编译器优化掉（可加
//go:noinline注释） - 示例：
func logError(msg string) { _, file, line, ok := runtime.Caller(1) if ok { fmt.Printf("[%s:%d] %sn", file, line, msg) } }
用 pprof 查看运行时 goroutine 堆栈快照
当程序疑似死锁、goroutine 泄漏，或 panic 发生前已有大量协程阻塞时，net/http/pprof 提供的 /debug/pprof/goroutine?debug=2 接口能导出所有 goroutine 的完整堆栈，比单点 PrintStack() 更全局。
立即学习“go语言免费学习笔记（深入）”；
- 需在服务中显式注册：
http.ListenAndServe(":6060", nil)并导入_ "net/http/pprof" -
?debug=2参数决定输出粒度：1 是摘要（只列状态），2 是完整堆栈（含变量值，注意敏感信息） - 该接口无认证，生产环境务必限制访问 IP 或关闭（设
GODEBUG=madvdontneed=1不影响此功能） - 拿到输出后可用
go tool pprof分析，但多数情况直接 grep 关键函数名更快
实际调试中最容易被忽略的是：堆栈信息本身不包含变量值，也不反映 channel 阻塞原因或 mutex 持有者。真要定位深层问题，得配合 pprof 的 mutex、block profile，或者用 delve 断点观察运行时状态。