Go中应优先用errors.Is/As判断错误而非==或反射；%w包装支持错误链遍历，%v会破坏链；自定义错误需实现Unwrap；高频路径避免反射和深度包装。
Go 中用 errors.Is 判断错误类型比 == 更安全
直接用 == 比较两个 error 值，只在它们是同一个底层指针或字符串错误时才成立；一旦错误被包装（比如用 fmt.Errorf("wrap: %w", err) 或 errors.Wrap），== 就失效了。
真实场景里，HTTP 客户端超时、数据库连接断开、文件不存在这些错误，经常被中间层层层包装。你写的 if err == os.ErrNotExist 很可能永远进不去。
- 一律改用
errors.Is(err, os.ErrNotExist)—— 它会递归解开%w包装链 -
errors.As(err, &target)用于提取底层具体错误类型（比如把包装后的*os.PathError解出来） - 自定义错误要实现
Unwrap() error方法，否则errors.Is和As不会往下钻
反射（reflect）在错误处理中几乎从不必要，且代价明确
有人想“通用地判断任意错误是否含某字段”或“自动提取错误里的 code 字段”，于是上 reflect.ValueOf(err).FieldByName("Code")。这不仅慢，还绕过了 Go 的类型安全和错误语义设计。
Go 的错误不是数据容器，而是行为接口。真正需要区分的错误，应该用公开的判定函数（如 pgx.ErrNoRows）、导出的变量（如 sql.ErrNoRows）或标准 errors.Is/As 协议。
立即学习“go语言免费学习笔记（深入）”；
- 反射访问错误字段的典型耗时是普通类型断言的 5–10 倍，且无法内联、逃逸分析更差
- 如果真要带结构化信息，用实现了
Unwrap()和Error()的自定义错误类型，别靠反射硬抠 - 日志打点需要额外字段？用
fmt.Errorf("failed to parse: %w, code=%d", err, code)+errors.Is配合，别在运行时靠反射捞
fmt.Errorf 的 %w 和 %v 混用会导致 errors.Is 失效
写成 fmt.Errorf("db query failed: %v", err) 看似能打印原始错误，但丢掉了包装关系 —— errors.Is(wrappedErr, sql.ErrNoRows) 返回 false。
只有 %w 才让 errors.Is 和 errors.As 可用。但 %w 有严格限制：只能接一个 error 类型值，不能是字符串、nil、或多个参数。
- 正确：
fmt.Errorf("timeout waiting for lock: %w", ctx.Err()) - 错误：
fmt.Errorf("lock failed (%v): %w", reason, ctx.Err())——%w必须是最后一个动词且唯一 - 错误：
fmt.Errorf("retry %d times: %w", n, nil)——%w后接nil会让整个错误变成nil，非常隐蔽
性能敏感路径（如高频 HTTP handler）应避免在错误路径里做反射或深度包装
一个每秒处理 5000 请求的服务，如果每次失败都调用 reflect.TypeOf(err) 或用 fmt.Errorf("handler failed: %w", err) 套三层，GC 压力和分配延迟会肉眼可见地上升。
这不是理论瓶颈：pprof 显示 runtime.mallocgc 和 reflect.valueInterface 在错误频发时可能进 Top 3。
- 高频路径优先用预定义错误变量（
var ErrInvalidInput = errors.New("invalid input")），不包装 - 必须记录上下文？用结构化日志字段（如
log.With("path", r.URL.Path).Error("db fail", "err", err)），而不是塞进错误字符串 - 调试期临时加包装可以，上线前务必删掉
fmt.Errorf("debug: %w", err)这类语句
错误链越深，errors.Is 查找越慢；反射一上，连慢都算不上，是“不可预测的卡顿”。这两件事在 Go 里本就不该凑一起用。
