Go 1.13 起通过 errors.Is/As 支持错误链判断，Go 1.20 增强错误包装与栈帧捕获能力；需结合 %w 包装、runtime.Caller 提取栈帧、结构化日志（如 zap + cockroachdb/errors）实现可追溯、完整、可归因的错误诊断链。
Go 1.13 引入了 errors.Is 和 errors.As，而 Go 1.20 起原生支持错误链（error wrapping）和调用栈捕获（runtime.Frame + errors.Caller），但默认 fmt.Errorf 只保留一层栈帧。要真正实现**可追溯的错误链+完整调用栈+明确错误来源**，需结合包装、栈帧提取与结构化记录。
使用 errors.Join 和 %w 包装形成错误链
用 %w 格式动词包装底层错误，保持错误链可展开；多错误聚合用 errors.Join，避免丢失任一原因：
- 包装时始终用
%w，而非%s或字符串拼接 - 上层函数不掩盖原始错误类型，方便
errors.As断言 - 示例：
return fmt.Errorf("failed to save user: %w", repo.Save(u))
手动捕获并附加调用栈信息
标准 fmt.Errorf 不自动记录栈帧，需主动调用 runtime.Caller 获取文件/行号，并注入错误中：
- 在关键错误生成点，用
runtime.Caller(1)获取调用方位置（1 表示上一层） - 封装为自定义 error 类型，嵌入
file:line和func信息 - 示例：
type StackError struct { Err error; File, Line int; Func string }，实现Error()和Unwrap()
用第三方库简化栈帧与链式记录（推荐 zap + fxamacker/cbor）
生产环境建议使用成熟方案，如 github.com/zaplog/zap 结合 github.com/cockroachdb/errors 或 go.uber.org/multierr：
立即学习“go语言免费学习笔记（深入）”；
cockroachdb/errors自动捕获全栈（含 goroutine ID、时间戳、调用路径），支持errors.Detailf注入上下文- 搭配 zap 的
With(zap.Error(err))可自动展开错误链与栈帧，输出结构化日志 - 避免自己解析
debug.PrintStack()—— 它是 stdout 副作用，不可控且非结构化
日志中统一打印错误链与栈（不依赖 panic）
不要等 panic 才看栈；在 if err != nil 分支中主动格式化错误链：
- 用
fmt.Printf("%+v\n", err)（%+v 触发 cockroachdb/errors 或自定义 error 的详细输出） - 若用标准库，可遍历链：
for i := 0; errors.Unwrap(err) != nil; i++ { err = errors.Unwrap(err) }，再配合runtime.Callers提取每层栈 - 关键：在 HTTP handler、DB transaction 等入口处统一 wrap + annotate，例如
errors.Wrapf(err, "handler.UserCreate at %s", r.URL.Path)
不复杂但容易忽略：错误链的价值不在“抛出”，而在“被读”——确保日志系统能解析它、监控能告警它、开发能一眼定位源头。从第一层 %w 开始，到最后一行 zap.Error 输出，整条链必须可穿透、可检索、可归因。
