fmt.Printf("%+v", err) 只显示最外层错误，因原生错误链不自动携带堆栈；需手动遍历 errors.Unwrap 并结合 runtime.Caller 或 StackTrace() 接口提取各层位置信息。
为什么 fmt.Printf("%+v", err) 有时只显示最外层错误？
Go 1.13 引入的错误链（error wrapping）机制让 errors.Unwrap 和 %+v 格式动作为可能，但默认的 fmt.Printf("%+v", err) 行为取决于错误类型是否实现了 fmt.Formatter。标准库中的 errors.New 和 fmt.Errorf（带 %w）包装后的错误，只有在使用 %+v 且底层支持时才会展开链——但很多第三方错误（如 github.com/pkg/errors 或自定义结构体）不自动输出完整堆栈。
- 只用
%v：永远只打印最外层Error()返回值 - 用
%+v：仅当错误实现了fmt.Formatter且显式支持展开（如github.com/pkg/errors），才可能显示堆栈；原生fmt.Errorf包装链在 Go 1.17+ 才对%+v输出简单链式描述，但无行号/文件 - 真正要看到每层错误 + 文件+行号+函数名，必须手动遍历
errors.Unwrap并结合运行时堆栈提取
如何手动遍历错误链并打印每一层的堆栈？
核心思路是：用 errors.Unwrap 循环解包，对每个非 nil 错误尝试获取其底层堆栈（前提是它保存了）。注意：不是所有错误都携带堆栈——只有显式捕获（如 debug.PrintStack()、runtime.Caller）或由支持堆栈的错误构造器（如 github.com/pkg/errors.Wrap、go.opentelemetry.io/otel/codes 配合 trace）创建的才有效。
- 优先检查错误是否实现了
StackTrace() errors.StackTrace（如github.com/pkg/errors） - 否则退回到
runtime.Caller获取当前错误创建点——但这只能拿到“这个 error 变量被赋值的位置”，不是原始 panic 点 - 避免无限循环：每次
Unwrap后检查是否等于前一层（防环引用）
func PrintErrorChain(err error) {
seen := map[error]bool{}
for i := 0; err != nil; i++ {
if seen[err] {
fmt.Printf(" [%d] %v (circular reference)\n", i, err)
break
}
seen[err] = true
fmt.Printf(" [%d] %v\n", i, err)
// 尝试获取 stack trace
if st, ok := err.(interface{ StackTrace() errors.StackTrace }); ok {
for _, f := range st.StackTrace() {
fmt.Printf(" %s\n", f)
}
} else if st, ok := err.(interface{ StackTrace() []uintptr }); ok {
// 兼容旧版 pkg/errors
for _, pc := range st.StackTrace() {
f := runtime.FuncForPC(pc)
if f != nil {
file, line := f.FileLine(pc)
fmt.Printf(" %s:%d %s\n", file, line, f.Name())
}
}
}
err = errors.Unwrap(err)
}
}
用 github.com/pkg/errors 还是原生 fmt.Errorf + errors.Is/As？
如果你需要可靠、可读性强的堆栈输出，github.com/pkg/errors 仍是目前最省心的选择——它的 Wrap、Wrapf 自动记录调用点，%+v 直接打印带文件行号的完整链。而原生 fmt.Errorf("... %w", err) 虽轻量、无依赖，但只保留错误语义链，不附带堆栈信息。
-
github.com/pkg/errors.Wrap(io.ErrUnexpectedEOF, "reading header")→ 打印时含header.go:42 -
fmt.Errorf("reading header: %w", io.ErrUnexpectedEOF)→%+v仅显示两层文字，无位置 - 兼容性：Go 1.13+ 的
errors.Is/errors.As对两者都有效，所以混合使用没问题 - 注意：Go 1.20+ 中
github.com/pkg/errors已归档，推荐迁移到golang.org/x/xerrors（已随 Go 1.13+ 标准库整合）或直接用原生 + 自定义堆栈捕获
如何给原生 fmt.Errorf 包装的错误补上堆栈？
可以在包装时手动捕获当前调用点，封装成一个辅助函数。这不是标准做法，但能兼顾无依赖和可观测性。
立即学习“go语言免费学习笔记（深入）”；
import (
"fmt"
"runtime"
)
func WrapWithStack(err error, message string) error {
if err == nil {
return nil
}
pc, file, line, _ := runtime.Caller(1)
f := runtime.FuncForPC(pc)
if f == nil {
return fmt.Errorf("%s: %w", message, err)
}
return fmt.Errorf("%s (%s:%d %s): %w", message, file, line, f.Name(), err)
}
// 使用示例：
// err := someIO()
// return WrapWithStack(err, "failed to parse config")
这种方式不会提供完整调用链堆栈，但至少每层包装都标出“谁包的”和“在哪包的”，配合 %+v 能清晰定位问题源头。真正的全链堆栈仍需像 pkg/errors 那样在每层都存 runtime.Callers，代价略高。
错误链不是越深越好，堆栈也不是越多越有用。关键是在日志上下文中，让开发或运维一眼看出「哪段业务逻辑触发了错误」以及「错误最初从哪个系统边界进来」——这两点比显示 15 层 runtime 函数更有价值。
