因为errors.new不记录调用位置，而pkg/errors.new在创建错误时主动调用runtime.callers捕获堆栈帧，使%+v可展开完整调用链；wrap同时添加消息和堆栈，withstack仅补充当前堆栈帧。
为什么 errors.New 不带堆栈，而你需要它
Go 标准库的 errors.New 返回的错误对象不包含调用堆栈，一旦错误在多层函数中传递，你根本不知道它最初在哪一行生成。调试时只能看到“failed to open file”，却找不到是哪个 os.Open 调用出的问题——这是线上排查最头疼的源头之一。
推荐用 github.com/pkg/errors（注意：不是官方 errors 包），它的核心价值是把错误创建和堆栈捕获绑定在一起。关键不是“加了堆栈”，而是“在错误诞生那一刻就快照堆栈”，后续再怎么包装、传递，原始位置不会丢。
示例对比：
err := errors.New("read timeout") // 无堆栈<br>err := pkgerrors.New("read timeout") // 自动捕获当前行号和调用链
pkgerrors.Wrap 和 pkgerrors.WithStack 的区别在哪
这两个函数都加堆栈，但触发时机不同，容易混用导致重复堆栈或漏捕获。
-
pkgerrors.WithStack(err)：只给已有错误err补一个新堆栈帧（即当前调用点），不改变原错误内容，适合“透传错误但标记当前位置” -
pkgerrors.Wrap(err, "failed to parse config")：在包裹错误的同时，既添加新消息，又记录当前堆栈——这才是最常用场景 - 别对
nil错误调用Wrap，它会 panic；先判空，或用pkgerrors.WrapIf（v0.9.1+） - 如果上游错误已经是
pkgerrors类型，Wrap会合并堆栈，不是简单叠加；但多次WithStack可能产生冗余帧
如何打印带完整堆栈的错误信息
直接 fmt.Println(err) 或 log.Printf("%v", err) 只显示错误消息，不输出堆栈。必须用 %+v 格式化动词。
示例：
err := pkgerrors.Wrap(io.EOF, "reading header")<br>fmt.Printf("%+v\n", err) // 输出含文件名、行号、调用链的完整堆栈
注意：%+v 是 pkgerrors 自定义的格式化行为，标准 fmt 对其他错误类型无效；若用 slog 或结构化日志，需调用 pkgerrors.MarshalJSON 或手动提取 pkgerrors.Cause(err).Error() 避免 panic。
常见坑：在 HTTP handler 中用 log.Printf("%v", err) 记录，结果日志里只有“internal error”，堆栈全丢了。
Go 1.13+ 官方 errors 包与 pkgerrors 共存怎么办
官方 errors.Is 和 errors.As 能识别 pkgerrors 包装的错误，但前提是底层错误没被覆盖。比如：
err := pkgerrors.Wrap(os.ErrNotExist, "config missing")<br>errors.Is(err, os.ErrNotExist) // true<br>errors.As(err, &pathErr) // true，可提取 *os.PathError
但如果你用 fmt.Errorf("wrap: %w", err) 包裹 pkgerrors 错误，Go 官方的 %w 会剥离 pkgerrors 的堆栈结构，只剩标准错误链——堆栈信息就此丢失。
所以：混合使用时，坚持用 pkgerrors.Wrap 替代 fmt.Errorf(...%w...)；所有错误创建和包装统一走 pkgerrors，避免中间混入标准 fmt.Errorf。
真正麻烦的是团队里有人悄悄改了包装方式，等线上报错堆栈断层，才想起查 git blame。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
