errors.new 和 fmt.errorf 无法打印堆栈，因它们只生成纯文本错误且不记录调用位置；需用 pkg/errors.new 或 pkg/errors.wrap 才能捕获和展开完整调用栈。
为什么 errors.New 和 fmt.Errorf 无法打印堆栈
因为它们只生成纯文本错误，不记录调用位置。哪怕你在 main 调用链第 5 层 panic，errors.New("failed") 输出也永远只有那一行字，没法知道错在哪个文件哪一行。
真正需要堆栈时，必须用支持上下文追踪的库——pkg/errors（注意不是标准库 errors）。
-
pkg/errors.New会在创建时捕获当前 goroutine 的调用栈 -
pkg/errors.Wrap可以在已有错误上叠加新信息和新栈帧，适合“包装上游错误”场景 - 别混用：用
pkg/errors创建的错误，就别再用fmt.Errorf("%w", err)包装，否则会丢失原始栈
如何正确打印带堆栈的错误
直接 fmt.println(err) 或 log.Print(err) 只显示错误消息，不显示堆栈。必须显式调用 pkg/errors 提供的格式化函数。
- 用
fmt.printf("%+v", err)—— 这是唯一能展开完整堆栈的方式 -
%v或%s仍只输出错误文本，和标准库行为一致 - 如果日志系统不支持
%+v（比如某些结构化日志库），需手动调用pkg/errors.StackTrace(err)转成字符串
示例：
立即学习“go语言免费学习笔记（深入）”；
err := pkgerrors.Wrap(io.ErrUnexpectedEOF, "reading header") fmt.Printf("%+vn", err)输出会包含从 Wrap 调用点开始，到最内层 io.ErrUnexpectedEOF 创建点的完整调用路径。
pkg/errors 在 go 1.13+ 中的兼容性问题
Go 1.13 引入了 errors.Is 和 errors.As，但它们对 pkg/errors 的错误类型支持有限——仅当错误是直接由 pkg/errors.New 或 pkg/errors.Wrap 创建时才可被识别；若中间经过 fmt.Errorf("%w", ...)，就会断掉包装链。
- 推荐统一用
pkg/errors.Cause(err)向下找根错误，再做类型判断 - 避免在已有
pkg/errors错误上使用fmt.Errorf("%w", err)，改用pkg/errors.Wrap(err, "...") - 如果项目已升级到 Go 1.20+，考虑迁移到标准库
fmt.Errorf("msg: %w", err)+runtime/debug.Stack()手动附加，或用github.com/charmbracelet/x/exp/errors等轻量替代
测试中验证堆栈是否生效的简单方法
别靠肉眼数行号，写个最小验证逻辑更可靠。
- 在测试函数里调用
pkg/errors.New("test")，然后用fmt.Sprintf("%+v", err)捕获输出 - 检查输出是否包含测试文件名和当前行号（例如
stacktrace_test.go:12） - 若没出现，大概率是 import 错了：
import "errors"覆盖了"github.com/pkg/errors"，注意别漏掉模块路径
堆栈不是“有了就行”，它得指向真实出错位置。一旦发现总是指向 pkg/errors 内部函数，说明你可能在 defer、闭包或 goroutine 里创建了错误——那里的调用栈已经变了。