Go错误默认不带堆栈，调试时应添加，生产用户错误需避免泄露，日志和跨goroutine传递时建议携带；推荐用pkg/errors或tracerr等库添加，打印用%+v，避免重复包装。
Go 中的错误默认不包含堆栈信息，这是设计使然——标准 error 接口只要求实现 Error() string 方法。是否需要堆栈，取决于错误的用途：调试阶段强烈建议携带堆栈；生产环境的用户可见错误通常不该暴露堆栈；而服务间调用或日志记录时，带堆栈的错误能极大提升排查效率。
什么时候该加堆栈？
不是所有错误都需要堆栈。核心判断原则是：该错误是否需要被开发者快速定位到源码位置。
- 内部函数失败后向上返回（如数据库查询失败、配置加载异常），应在首次出错处捕获并附加堆栈
- HTTP handler 中返回给前端的错误（如
400 Bad Request）不应含堆栈，避免信息泄露 - 写入日志的错误建议带堆栈，尤其在 warn 或 error 级别
- 跨 goroutine 传递错误（如 worker pool）时，原始堆栈容易丢失，需显式保留
怎么加堆栈？推荐方案
Go 1.13+ 原生支持错误链（%w）和 errors.Unwrap，但不自带堆栈。主流做法是用成熟库补充：
-
github.com/pkg/errors（经典，已归档但稳定）：用
errors.Wrap(err, "xxx")或errors.WithStack(err) - github.com/ztrue/tracerr：轻量、零依赖，自动捕获堆栈，支持格式化输出
-
Go 1.22+ 的 errors 包增强：可结合
fmt.Errorf("%w", err)+ 自定义 error 类型实现堆栈感知（需自己封装）
不建议手动调用 runtime.Caller 拼接堆栈——易出错、性能差、可读性低。
怎么用好堆栈？关键习惯
加了堆栈不等于会用。真正发挥价值要配合使用方式：
- 日志打印时用
fmt.Printf("%+v", err)（%+v是关键，否则只显示字符串） - 避免在多层包装中重复加堆栈（比如 A→B→C 都 Wrap），应在最外层或首次错误点加一次即可
- 对外暴露的 API 返回 error 时，若需调试，可通过 feature flag 控制是否注入堆栈，兼顾安全与可观测性
- 测试中可断言错误是否含特定堆栈帧（如用
tracerr.StackTrace(err)检查），确保关键路径有追踪能力
基本上就这些。堆栈不是越多越好，而是要在“可定位”和“可维护”之间找平衡。Go 的简洁哲学依然适用：默认不带，需要时清晰、克制、可选地加上。
