errors.Wrap没打出堆栈的根本原因是输出方式错误，必须用fmt.Printf("%+v", err)才能显示文件名和行号，%v和err.Error()会丢失堆栈信息。
errors.Wrap 为什么没打出堆栈？
写了 errors.Wrap(err, "xxx")，但 fmt.Println(err) 或 log.Print(err) 只显示错误文本，没看到文件名和行号——根本原因不是代码写错了，而是输出方式不对。
必须用 fmt.Printf("%+v", err) 才能展开调用帧；%+v 是触发堆栈打印的开关，%v 和 err.Error() 都会丢掉所有堆栈信息。
- 确保导入的是
github.com/pkg/errors，不是标准库errors（后者没有堆栈能力） - 被包装的上游错误本身也得是带堆栈的（比如也是用
errors.Wrap或errors.New创建的），否则再包也没用 - 日志中直接写
log.Printf("%+v", err)，别用log.Println(err)
fmt.Errorf("%w", err) 和 errors.Wrap 到底怎么选？
Go 1.13+ 原生支持 %w，但它不记录堆栈；errors.Wrap 既保链又记堆栈。两者不是替代关系，而是分工明确：
-
fmt.Errorf("xxx: %w", err)：只做错误链传递，适合中间层透传、类型判断（errors.Is/errors.As），性能轻量 -
errors.Wrap(err, "xxx")：在保链基础上额外捕获当前调用点（文件+行号），适合错误“发生处”或关键路径入口 - 混用没问题：底层用
%w透传，最外层用errors.Wrap打点堆栈，这是推荐组合 - 别在循环里反复
Wrap同一个错误，可能累积冗余帧，调试时反而难读
errors.Cause 和 errors.Is 的实际用途
errors.Cause(err)（来自 pkg/errors）和 errors.Is(err, target)（标准库）解决的是不同问题：
立即学习“go语言免费学习笔记（深入）”；
-
errors.Cause直接跳过所有包装，拿到最内层原始 error，方便做类型断言或重试逻辑，比如if e, ok := errors.Cause(err).(*os.PathError); ok { ... } -
errors.Is是递归Unwrap直到匹配或 nil，安全判断是否是某个已知错误（如os.ErrNotExist），比err == os.ErrNotExist可靠得多 - 注意：
errors.Is不依赖堆栈，只依赖错误链；即使你用%w包了十层，它也能正确识别底层错误 - 如果中间某层用了
fmt.Errorf("xxx: %v", err)，链就断了，errors.Is会失效
HTTP handler 中错误堆栈的安全部署
handler 里把 %+v 输出的完整堆栈直接返回给前端，等于把源码路径、函数名、甚至变量值全暴露出去。
- 对外响应一律用
err.Error()或自定义脱敏 message，绝不用%+v - 服务端日志才用
log.Printf("req=%s err=%+v", r.URL.Path, err)，确保可追溯 - 只在错误真正产生的地方 Wrap 一次（比如 DB 查询失败、文件打开失败），不要在每层 handler 都包一遍，否则日志全是重复前缀
- 避免在 Wrap 消息里拼接敏感字段，如
errors.Wrap(err, "user "+u.Email+" auth failed")—— 邮箱可能进日志
堆栈不是越多越好，关键在源头打点、链路不断、输出可控。漏掉 %+v 或误用 %v 是最常被忽略的环节。
