应使用 errors.Is 判断底层错误类型，因其能递归遍历 %w 包装的错误链；用 errors.As 提取包装错误中的具体值；避免字符串匹配和裸指针比较；确保全程使用 %w 保持错误链完整。
直接用 errors.Is 判断底层错误类型，别用 == 或 strings.Contains
Go 的错误链（error chain）让 err == io.EOF 失效，因为包装后的错误不再是同一个指针。常见误写是：if err == io.EOF 或 strings.Contains(err.Error(), "EOF") —— 前者在 fmt.Errorf("read failed: %w", io.EOF) 下永远为 false，后者脆弱且无法处理多语言错误信息。
正确做法始终用 errors.Is：
if errors.Is(err, io.EOF) {
// 处理 EOF
}
它会递归遍历 %w 包装的错误链，安全可靠。同理，自定义错误也应实现 Unwrap() 方法以支持该机制。
用 errors.As 提取具体错误值，而不是类型断言嵌套
当需要访问包装错误中的原始结构体字段（比如 *os.PathError 的 Path 字段），很多人写成：if e, ok := err.(*os.PathError); ok { ... } —— 这在错误被包装后必然失败。
立即学习“go语言免费学习笔记（深入）”；
errors.As 是专为此设计的：
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("failed on path: %s", pathErr.Path)
}
它同样遍历错误链，找到第一个匹配类型的错误并赋值。注意传入的是指针地址，不是值；且目标变量必须是指针类型（如 *os.PathError）。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
避免在 defer 中重复检查同一 err 变量
典型反模式：defer func() { if err != nil { log.Println(err) } }()，但函数内又多次对 err 赋值并检查，导致日志重复或掩盖真实错误源。
更可控的做法是：只在明确出口处处理错误，或使用带上下文的封装：
- 把 cleanup 逻辑和错误处理分离，比如用
defer closeFile(f)，其中closeFile不依赖外部err - 若必须 defer 日志，改用
defer func(e error) { if e != nil { log.Print(e) } }(err)，捕获调用时的快照值 - 优先用
return fmt.Errorf("xxx: %w", err)向上透传，由最外层统一处理，而非每层都if err != nil
用自定义错误类型 + 错误码替代字符串匹配
靠 err.Error() 做分支判断（如 if strings.Contains(err.Error(), "timeout")）极不可靠：拼写变化、翻译、格式调整都会破坏逻辑。
推荐定义带错误码的结构体：
type AppError struct {
Code int
Err error
}
func (e *AppError) Error() string { return e.Err.Error() }
func (e *AppError) Unwrap() error { return e.Err }
然后用 errors.As 提取并比对 Code：
var appErr *AppError
if errors.As(err, &appErr) && appErr.Code == ErrCodeTimeout {
// 处理超时
}
这样既保持错误链兼容性，又让错误分类清晰、可测试、易维护。
真正容易被忽略的是：哪怕用了 errors.Is 和 errors.As，如果中间某层用 fmt.Errorf("%s", err) 替代 %w，整个错误链就断了 —— 检查会静默失效。务必确认所有包装都用 %w。
