Go错误链丢失的典型现象是使用fmt.Errorf("xxx")或"%v"包装错误导致底层os.PathError等原始错误消失，正确做法是全程使用"%w"包装并用errors.Is/As检查、%+v打印完整链路。
Go 错误链丢失的典型现象
调用链里 fmt.Errorf("xxx") 一包，底层真实的 os.PathError 或 sql.ErrNoRows 就没了——日志里只剩“处理用户订单失败”，根本看不出是磁盘满还是数据库连不上。
这不是 Go 的 bug，是没用对错误包装方式。Go 1.13 引入的错误链（Unwrap）机制默认只在用 fmt.Errorf("%w", err) 时才保留底层错误，其他写法全断链。
-
fmt.Errorf("failed: %v", err)→ 彻底丢原始错误，只剩字符串 -
errors.Wrap(err, "xxx")（第三方库）→ 虽保留但不兼容标准errors.Is/errors.As -
fmt.Errorf("xxx: %w", err)→ 正确，支持标准错误检查和递归展开
多层函数间传递错误的实操写法
每一层都该决定：是终止错误（返回给上层）、还是包装后继续传？关键看这层是否添加了新上下文，且是否需要被上层识别特定错误类型。
比如 HTTP handler 调用 service，service 调用 repo：handler 不该直接 return err，而应包装成带请求 ID 的错误；repo 层则必须用 %w 向 service 暴露原始 DB 错误。
立即学习“go语言免费学习笔记（深入）”；
- 底层（如 DB 查询）：直接返回原始错误，或用
%w包一层加 SQL 上下文，例如fmt.Errorf("query user by id %d: %w", id, err) - 中间层（如 service）：只用
%w包装，不改错误类型，例如fmt.Errorf("get user profile: %w", repo.GetUser(ctx, id)) - 顶层（如 HTTP handler）：可用
%v或%s输出给用户，但记录日志时必须用%+v打印完整错误链
检查和提取底层错误的正确姿势
别再靠 strings.Contains(err.Error(), "no such file") 做判断——脆弱、易错、不跨平台。Go 标准库提供了稳定接口。
errors.Is(err, os.ErrNotExist) 和 errors.As(err, &pathErr) 是唯一推荐方式，它们会顺着 %w 链一直往下找，直到匹配或到头。
- 判断是否是某类错误：用
errors.Is(err, targetErr)，比如errors.Is(err, sql.ErrNoRows) - 提取具体错误实例：用
errors.As(err, &e)，例如提取*os.PathError获取Path字段 - 打印完整链路：日志中用
fmt.Printf("err: %+v\n", err)，%+v是关键，缺它就只显示最外层
容易被忽略的 panic 和 defer 场景
panic 后 recover 到的 err 是 interface{}，不是 error 类型；defer 里用 log.Fatal(err) 会直接退出，根本来不及展开错误链。
更隐蔽的是：有些中间件或框架（比如 Gin 的 c.Error()）内部做了错误转换，可能把 %w 包装的错误转成了普通字符串——得看源码确认它是否调用了 fmt.Sprintf("%+v", err)。
- recover 后想继续处理错误？先做类型断言：
if e, ok := err.(error); ok { /* 处理 e */ } - defer 中记录错误：别用
log.Fatal，改用log.Printf("deferred error: %+v", err) - 用第三方错误库前，确认它是否实现了
Unwrap() error方法，否则errors.Is无效
错误链不是自动生效的，它依赖每一层都严格使用 %w，漏掉一次，下面所有上下文就永远消失了。最麻烦的不是写错，而是某次临时加的日志语句里用了 %v 替代 %w，然后线上查三天查不出磁盘 IO 错误到底发生在哪一层。
