Go 1.13 的 errors.Is/As 与 fmt.Errorf("%w") 构成错误链标准，%w 仅在需向上追溯原始错误时使用，要求参数为 error 类型；errors.As 失败主因是传值而非指针、目标非具体类型或链中断；自定义错误须实现 Unwrap() 方法。
Go 1.13 引入的 errors.Is 和 errors.As 配合 fmt.Errorf 的 %w 动词，构成了现代 Go 错误链（error wrapping）的事实标准。不使用 %w 包装、或错误调用 errors.As，是绝大多数“错误判断失效”的根源。
什么时候必须用 %w 而不是 %v 或字符串拼接
只有当你希望下游能通过 errors.Is 或 errors.As 向上追溯原始错误时，才需要 %w。它不是为了“记录更详细信息”，而是为了构建可解包的错误链。
-
%w要求第二个参数必须是error类型，否则编译报错：cannot use ... (type string) as type error - 用
%v、%s或+ " failed: " + err.Error()会丢失原始错误类型和值，errors.Is(err, io.EOF)必然返回false - 包装多层时，每层都必须用
%w，漏一层就断链：err := fmt.Errorf("read header: %w", innerErr) // ✅
err = fmt.Errorf("process request: %v", err) // ❌ 断链
errors.As 失败的三个常见原因
errors.As 用于提取链中某个特定类型的错误（比如自定义错误或 *os.PathError），失败往往不是因为没包装，而是调用方式不对。
- 目标变量必须是指针（
&target），传值会导致无法写入：errors.As(err, target)永远不生效 - 目标类型必须是具体类型或接口，不能是
error本身：var e error; errors.As(err, &e)不起作用 - 如果链中存在多个同类型错误（如嵌套两次
*MyError），errors.As只返回最外层匹配的那个，不会跳过中间层
自定义错误类型如何支持正确包装与解包
如果你定义了带字段的错误（如含重试次数、请求 ID），需同时实现 Unwrap() error 方法，否则 %w 包装后无法被 errors.Is / errors.As 穿透。
立即学习“go语言免费学习笔记（深入）”；
type MyError struct {
Msg string
Code int
Err error // 原始错误，供 Unwrap 返回
}
func (e *MyError) Error() string { return e.Msg }
func (e *MyError) Unwrap() error { return e.Err }
注意：Unwrap 方法必须返回一个 error，且不能返回 nil（除非你确定这是叶子节点）；若想支持多级解包（比如同时暴露 Code 和底层 Err），可额外实现 Is(error) bool 或 As(interface{}) bool，但通常不必要——标准库链式遍历已足够。
日志、HTTP 响应等场景下要不要保留错误链
不要直接把包装后的错误原样打日志或返回给前端。错误链是给程序逻辑用的，不是给人看的。
- 日志中建议用
fmt.Sprintf("%+v", err)（需导入github.com/pkg/errors）或 Go 1.20+ 的fmt.Printf("%+v", err)查看完整链；生产环境日志则应提取关键字段（如err.Error()+ 自定义 code） - HTTP API 返回错误时，应解包出用户可读信息，而非暴露底层细节：
if errors.Is(err, sql.ErrNoRows) { return JSON{Code: 404, Msg: "not found"} } - 跨服务 RPC（如 gRPC）中，错误链无法序列化传递，需在边界处显式转换为状态码+消息，接收方再根据状态码重建本地错误
错误链真正的复杂点不在怎么写，而在“在哪断”——哪些错误该继续包装，哪些该吞掉或转成新错误。比如数据库连接失败可以包装，但密码校验失败绝不能把底层 bcrypt 错误暴露出去。这取决于业务语义，不是技术规则能覆盖的。
