Errors.new 和 fmt.errorf 不显示堆栈，因为标准 error 接口不强制携带调用信息，二者仅返回字符串包装；需用 errors.wrap、withstack 或 %+v 才能输出完整堆栈。
为什么 errors.New 和 fmt.Errorf 不显示堆栈？
因为 go 标准库的 error 接口只要求实现 Error() String 方法，不强制携带调用位置信息。你用 errors.New("xxx") 或 fmt.Errorf("xxx") 创建的 error，本质上只是字符串包装，runtime.Caller 没被调用过，自然没堆栈。
常见错误现象：日志里只看到 "failed to open config file"，完全不知道是哪个函数、哪一行触发的。
- 使用场景：调试生产环境偶发 panic 或链式错误时，必须定位源头
- 解决方向：改用能捕获调用点的 error 构造方式，比如
github.com/pkg/errors的errors.Wrap或 Go 1.13+ 的fmt.Errorf("%w", err) - 注意兼容性：
pkg/errors在 Go 1.13 后逐渐被原生%w取代，但它的errors.WithStack和errors.print仍有不可替代性
用 pkg/errors 包裹错误时，Wrap 和 WithStack 有什么区别？
errors.Wrap 是最常用的方式，它在错误消息前加前缀，并记录当前调用点；errors.WithStack 则不改消息，只单纯附加堆栈——适合不想污染原始错误文本，但又需要追踪路径的场景。
示例对比：
立即学习“go语言免费学习笔记（深入）”；
// Wrap：消息被修改，堆栈从这里开始 err := errors.Wrap(io.ErrUnexpectedEOF, "reading header") // WithStack：消息不变，但多了堆栈 err := errors.WithStack(io.ErrUnexpectedEOF)- 参数差异：
Wrap(err, msg)要求第一个参数是 error，第二个是 string；WithStack(err)只接受一个 error - 性能影响：两者都会调用
runtime.Caller，开销接近，但频繁调用（如循环内）仍应避免 - 容易踩的坑：别对同一个 error 多次
Wrap，会导致堆栈重复叠加，日志冗长难读
如何让日志输出完整堆栈，而不是只有一行 error: xxx？
直接打印 err.Error() 永远看不到堆栈。必须用 pkg/errors 提供的 errors.Print，或自己调用 errors.StackTrace(err) 格式化。
实操建议：
- 开发/测试环境：用
errors.Print(err)直接输出到 stderr，带文件名、行号、函数名 - 生产环境：避免直接调
Print（它会 panic 如果 err 不含 stack），改用fmt.printf("%+v", err)—— 注意是%+v，不是%v - 如果用了 zap/zaplog 等结构化日志，需手动提取：
stack := errors.GetStack(err)，再作为字段写入 - 常见错误：误用
fmt.Println(err)或log.Println(err)，它们都只调Error()方法，堆栈被丢弃
Go 1.13+ 原生 %w 能替代 pkg/errors 吗？
可以做错误链传递，但不能直接输出堆栈。原生 fmt.Errorf("xxx: %w", err) 支持 errors.Is/errors.As，也保留了底层 error，但它不记录自己的调用点，所以整条链里只有最内层 error（如果有）带堆栈。
- 关键限制：标准库没有等价于
errors.Print或%+v的堆栈展开机制 - 混合使用可行：
pkg/errors.Wrap包裹最外层，内部用%w，这样堆栈有、链路也清晰 - 容易忽略的点：如果你依赖
errors.Cause解包，要注意它对原生%w错误返回的是包装后的 error，不是原始值，行为和旧版不完全一致
堆栈不是自动附带的属性，是显式采集的结果。每次封装都要问一句：这里是不是错误传播的关键节点？如果不是，就别 Wrap；如果是，就得确保下游能真正看到那一段 trace。