Go标准error接口仅要求Error()方法返回字符串，fmt.Errorf默认不记录调用位置，故无栈信息；需用xerrors、pkg/errors等包装或手动调用runtime.Caller才能附加文件名、行号和函数名。
为什么 fmt.Errorf 默认不带栈信息？
Go 的标准错误（error 接口）本身不携带调用位置，fmt.Errorf("msg") 返回的只是纯文本错误，哪怕用了 %w 包裹底层错误，也不会自动附加栈帧。想拿到类似 panic 时的文件名、行号、函数名，得靠第三方包或 Go 1.17+ 的 runtime/debug.Stack() 手动捕获——但后者开销大、不精准（抓的是当前 goroutine 栈，不是错误创建点）。
用 github.com/pkg/errors 或 golang.org/x/xerrors 包装错误
这两个库都支持在错误创建时记录栈，且兼容标准 error 接口。推荐优先用 xerrors（官方维护，更轻量），但注意它已在 Go 1.20+ 被标记为 deprecated；若项目已升级到 Go 1.20+，应改用 fmt.Errorf 配合 %w 和内置的 errors.Unwrap，再用 runtime.Caller 手动补栈——不过更稳妥的做法仍是用 github.com/cockroachdb/errors 或 github.com/zeebo/errs 等活跃维护的替代品。
-
xerrors.Errorf("failed to open file: %w", err)会在错误中嵌入创建时的栈 - 用
xerrors.WithStack(err)可给已有错误追加栈（比如从os.Open拿到的原始*os.PathError） - 日志输出时调用
xerrors.Detail(err)或fmt.Sprintf("%+v", err)才能展开栈（%v不会显示）
用 fmt.Sprintf("%+v", err) 输出带栈的字符串
这是最直接的日志化方式，但依赖错误对象是否真正携带栈信息。如果错误来自 fmt.Errorf 或 errors.New，%+v 什么都不会多打；只有经 xerrors、pkg/errors 或 cockroachdb/errors 包装过的错误才有效。
- 确保导入对应包（如
import "golang.org/x/xerrors"） - 构造错误时显式用
xerrors.Errorf或xerrors.WithStack - 日志语句写成
log.Printf("operation failed: %+v", err)，而非%v - 注意：某些日志库（如
log/slog）默认只调用Error() string方法，不会触发%+v行为，需手动格式化后再传入
避免在 defer 中用 recover() 捕获并转成带栈 error
有人试图用 defer + recover() 拦截 panic，再用 debug.Stack() 构造错误——这确实能得到完整栈，但代价高（分配内存、阻塞 goroutine）、语义错乱（把 panic 当 error 处理），且栈是 panic 发生点，不是原始错误创建点。真正需要的是「错误发生时立刻记下位置」，不是「崩溃后抢救现场」。
立即学习“go语言免费学习笔记（深入）”；
- 除非你明确要记录 panic 场景，否则不要走这条路径
-
debug.Stack()返回的是[]byte，需string()转换，且包含大量冗余帧（如 runtime.* 函数），需裁剪 - 更安全的做法：所有关键错误路径统一用包装函数，例如
func E(msg string, args ...interface{}) error { return xerrors.Errorf(msg, args...) }
真正难的不是怎么打栈，而是让栈出现在该出现的地方——错误创建那一刻就包装，而不是等它传到日志层才想起来补。很多人卡在最后一步：以为只要日志里写 %+v 就万事大吉，结果发现输出还是没行号。问题不在格式化，而在上游错误压根没栈。
