runtime.Callers 返回 uintptr 切片，需配合 runtime.FuncForPC(p-1) 和 runtime.Frame 解析函数名、文件路径与行号；起始跳过帧数建议为 2，pcs 长度至少 64，解析时须减 1 防止行号偏移。
runtime.Callers 怎么拿到带文件行号的调用栈
它本身只返回一个 []uintptr，不带任何格式化信息，直接打印就是一串数字。必须配合 runtime.Frame 和 runtime.FuncForPC 才能解析出函数名、文件路径和行号。
常见错误是只调用 runtime.Callers(1, pcs) 却忘了后续解析——结果日志里只看到地址，看不出哪一行出的问题。
- 起始跳过帧数建议用
2：1 是Callers自身，2 是封装它的错误构造函数 -
pcs切片长度至少为 64，太小会截断深层调用链（比如中间经过多个中间件或 defer） - 解析时需用
runtime.FuncForPC(p - 1)（减 1），否则可能定位到下一条指令，行号偏移 +1
怎么把堆栈塞进 error 接口里不破坏原有行为
Go 的 error 接口只要实现 Error() string 就行，但想保留原始错误的底层类型（比如做 errors.Is 或 errors.As 判断），就不能简单拼字符串。
推荐用“包装型错误”：嵌入原始 error 字段，并在 Error() 中拼接堆栈。这样既可格式化输出，又不影响类型断言和错误链遍历。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 不要用
fmt.Errorf("%w: %s", err, stackStr)直接包一层——这会丢失原始错误的堆栈，只留最外层 - 要手动实现
Unwrap() error方法返回嵌入的err，否则errors.Unwrap拿不到下一层 - 如果原始错误本身已带堆栈（如
github.com/pkg/errors），注意避免重复叠加
为什么 fmt.Printf("%+v", err) 有时不显示堆栈
因为 %+v 是否展开堆栈，取决于错误类型是否实现了 fmt.Formatter 接口。标准库 error 没实现，所以默认只调 Error() 方法。
如果你自定义的错误想支持 %+v 显示完整调用链，必须显式实现 Format 方法，并识别 '+' 动作符。
- 判断
verb == '+' && v.Kind() == 'v'时才输出堆栈详情 - 别漏掉
fmt.Fprintf(s, "%s\n", err.Error())主体，否则%v会失效 - 第三方库如
github.com/pkg/errors或golang.org/x/xerrors就是靠这个机制支持%+v
性能和生产环境要注意什么
每次调用 runtime.Callers + 解析帧信息，开销比普通错误创建高 5–10 倍。高频路径（如循环内、HTTP handler 入口）慎用。
更关键的是：堆栈信息会延长错误生命周期，若错误被长期持有（比如塞进 map 或 channel），可能导致 GC 无法回收相关栈帧引用的变量，间接引发内存泄漏。
- 建议只在明确需要诊断的错误路径上启用（如非预期 panic、业务校验失败）
- 可通过环境变量或配置开关控制是否采集堆栈，上线后默认关闭
- 避免在
defer func() { ... }()里无条件调用——recover 到的 panic 错误本身已有堆栈，再加一层反而干扰判断
真正难的不是怎么拿到堆栈，而是决定在哪一层截断、保留多少帧、以及如何让下游工具（比如 Sentry、ELK）能正确提取和聚合这些信息。这些细节不写死在代码里，就很容易变成日志噪音。
