怎么在 panic 时拿到带文件行号的完整堆栈
Go 默认的 panic 输出只到第一层调用，深层函数调用链被截断，根本看不出哪一行触发了问题。这不是 Go 不支持，而是默认 runtime 没开启完整符号信息回溯。
实操建议：
- 启动时加
-gcflags="all=-l"禁用内联（尤其对测试/调试阶段），否则某些函数被内联后堆栈会跳过关键帧 - 确保编译时没加
-ldflags="-s -w"—— 这俩参数会剥离调试符号，runtime/debug.PrintStack()和runtime.Stack()返回的都是 ??:0 - 直接用
debug.PrintStack()比recover()+fmt.Printf("%+v", err)更可靠，后者依赖 error 是否实现了StackTrace()方法
errors.Wrap 和 errors.WithStack 在生产环境该选哪个
pkg/errors 已归档，但大量老项目还在用。它的 Wrap 和 WithStack 行为差异极容易踩坑：前者只在 wrap 时捕获一次堆栈，后者每次调用都重录堆栈。
常见错误现象：
立即学习“go语言免费学习笔记（深入）”；
- 用
errors.WithStack(fmt.Errorf("..."))包裹一个已带堆栈的 error，结果最外层堆栈指向WithStack调用点，丢失原始出错位置 - 在中间件或 defer 中反复
WithStack，堆栈层层叠加，日志里看到 10 层重复的同一行
使用场景建议：
- 只在**错误首次生成处**（比如 DB 查询失败、HTTP 解析异常）用
errors.WithStack - 后续传递中统一用
errors.Wrap或fmt.Errorf("xxx: %w", err)—— 它们复用原始堆栈，不污染调用链 - Go 1.13+ 原生
%w格式化已能透传堆栈，只要底层 error 实现了Unwrap()，无需额外包
runtime.Stack() 返回的 []byte 怎么解析成可读堆栈
runtime.Stack() 返回的是原始字节切片，直接打印是乱码或截断内容，不是格式化后的字符串。很多人卡在这一步，以为它“不能用”。
实操建议：
- 必须传
true作为第二个参数：runtime.Stack(buf, true)，否则只返回当前 goroutine 的简略信息 - 别忘了
buf要预分配足够空间（比如make([]byte, 1024*1024)），否则返回 false 且无提示 - 结果里含多 goroutine 信息，grep
"created by"或"goroutine X ["可快速定位主干路径；真正报错的函数通常在每个 goroutine 块的末尾几行
示例片段：
buf := make([]byte, 1024*1024)
n := runtime.Stack(buf, true)
log.Printf("stack:\n%s", string(buf[:n]))
为什么 fmt.Printf("%+v", err) 有时不显示堆栈，有时显示三行就截断
这取决于 error 类型是否实现了 github.com/pkg/errors 定义的 Formatter 接口，以及你用的是哪个版本的 pkg/errors 或替代库（如 github.com/go-errors/errors）。
参数差异和兼容性影响：
-
pkg/errorsv0.8.1+ 的%+v会尝试展开所有 wrapped error 并显示完整堆栈；旧版只展一层 - 如果 error 是
fmt.Errorf("xxx: %w", otherErr)且otherErr没实现Formatter，%+v就退化为普通%v，堆栈消失 - 某些日志库（如
logrus）默认用%+v，但若 error 来自net/http等标准库，它们不带堆栈，自然打不出来
最容易被忽略的地方是：堆栈不是 error 的“属性”，而是创建时捕获的快照。一旦 error 被序列化（比如 JSON 编码）、跨进程传递、或经过不保留堆栈的包装，它就永远丢失了。
