errors.New 不捕获堆栈，pkg/errors.New/Wrap 通过 runtime.Callers 记录 PC、文件和行号，使 %+v 可展开；迁移时优先用 errors.Is/As，需原始错误用 Cause，避免混用 Unwrap/Cause 导致堆栈丢失。
为什么 errors.New 打不出堆栈，而 pkg/errors 可以
因为 errors.New 只返回一个带字符串的 error 接口实现，不记录调用位置；pkg/errors 的 errors.New 和 errors.Wrap 会在创建时捕获 runtime.Callers，把 PC、文件名、行号存进结构体里。没有这步，%+v 就没法展开堆栈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 所有新错误创建统一用
pkg/errors.New或errors.Errorf，别混用标准库errors.New - 在关键入口（如 HTTP handler、CLI 命令执行点）用
errors.WithStack包一层，避免漏掉顶层调用上下文 - 注意
errors.Wrap是“包装已有 error”，不是“新建 error”——传入nil会 panic，得先判空
迁移时 errors.Cause 和 errors.Unwrap 怎么选
errors.Cause 是 pkg/errors 自己的解包逻辑，会一直往下找最内层非包装 error；errors.Unwrap 是 Go 1.13+ 标准库接口，只解一层。两者行为不等价，混用容易丢堆栈或误判类型。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 升级到 Go 1.13+ 后，优先用标准库
errors.Is和errors.As判断错误类型和值，它们兼容pkg/errors的包装结构 - 需要完整原始 error（比如查 SQL 错误码）时用
errors.Cause(err)；仅需检查是否为某类包装错误时，用errors.As(err, &target) - 别在日志里直接
fmt.Printf("%+v", errors.Unwrap(err))—— 它只剥一层，%+v又会把剩下的包装体再展开，堆栈重复显示
fmt.Printf("%+v", err) 不出堆栈？检查这三个地方
常见现象：明明用了 pkg/errors，但 %+v 输出还是没文件行号，只有字符串。问题通常不在打印本身，而在 error 构造或传递过程被“擦除”了。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 确认 error 没被强制转成标准
error接口后又用errors.New二次包装——比如return errors.New(err.Error())，这会丢掉所有堆栈 - 检查是否用了
fmt.Sprintf("%v", err)或log.Print(err)—— 这些只调Error()方法，不会触发%+v的扩展格式，必须显式写%+v - 如果 error 经过 JSON 编码/解码（比如发到日志服务），
pkg/errors的堆栈字段不会自动序列化，得自己加MarshalJSON方法或换用github.com/go-errors/errors
Go 1.20+ 迁移后要不要删掉 pkg/errors
可以删，但不是无痛切换。标准库 errors 和 fmt 在 1.20 已支持 %w 和多层 Unwrap，但缺失两个关键能力：Frame 级别的源码位置控制、以及 %+v 中按调用深度缩进显示堆栈。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 纯内部服务、错误链不深、不依赖堆栈可视化调试的项目，可逐步替换为
fmt.Errorf("msg: %w", err)+errors.Is/As - 仍需精确控制哪一层打堆栈（比如跳过中间工具函数），保留
pkg/errors更省事；它的Frame.Skip参数比标准库灵活 - 注意
pkg/errors已归档（archive），不再维护，长期项目建议用github.com/ztrue/tracerr或自己封装一层轻量 wrapper
真正麻烦的从来不是换函数名，而是那些散落在 if/else 分支里、没 Wrap 就直接 return 的 error，它们一旦漏掉，整条链就断了。
