应使用 errors.Is 和 errors.As 替代 == 判断错误类型，因其可穿透多层 %w 包装；自定义错误需显式实现 Unwrap 方法；推荐 defer 统一处理错误，避免循环中重复判断。
用 errors.Is 和 errors.As 替代 == 判断错误类型
直接用 err == io.EOF 或 err == sql.ErrNoRows 看似简单，但一旦错误被包装（比如通过 fmt.Errorf("failed: %w", err)），原始错误就藏在底层，== 会失效。这时候必须用 errors.Is 检查是否“是”某个错误，用 errors.As 提取具体错误类型。
-
errors.Is(err, io.EOF)能穿透任意层%w包装，安全判断语义相等 -
errors.As(err, &target)可以把包装后的错误还原成原始结构体指针，方便访问字段或方法 - 避免写
strings.Contains(err.Error(), "no rows")—— 依赖字符串易断裂，且无法跨语言本地化
定义自定义错误类型并实现 Unwrap 方法
当你需要组合多个错误上下文（如重试、中间件、日志装饰）又希望下游能精准识别时，不能只靠 fmt.Errorf("%w")。应定义结构体错误，并显式实现 Unwrap() 方法，控制错误链的展开逻辑。
type RetryError struct {
Op string
Err error
Atts map[string]string
}
func (e *RetryError) Error() string { return fmt.Sprintf("retry failed in %s: %v", e.Op, e.Err) }
func (e *RetryError) Unwrap() error { return e.Err }
- 这样
errors.Is(err, io.EOF)在遇到&RetryError{Err: io.EOF}时仍能命中 - 若不想让某层错误参与判断（比如日志装饰层），可让
Unwrap()返回nil - 注意：不要在
Unwrap()中返回新错误或做副作用操作，它应是纯函数
用 defer + 自定义 error handler 统一收口错误处理
在 HTTP handler、CLI 命令或数据库事务中，重复写 if err != nil { return err } 不仅冗余，还容易漏掉日志、监控或状态码映射。更可靠的方式是用 defer 注册一个错误处理器，在函数退出前集中响应。
- 定义
type ErrorHandler func(error) error，并在入口处defer errorHandler(err) - handler 内部可统一做：
log.Error()、metrics.Inc("error", err.Type())、http.Error(w, msg, code) - 关键点：确保
err是函数作用域内最后赋值的那个变量（例如命名返回参数err error），否则defer捕获的是初始零值
避免在循环中对每个 err 都做完整判断
常见反模式：遍历切片时，对每个元素调用函数后都写一遍 if errors.Is(err, ...) { continue } 或 if err != nil { return err }。这会导致逻辑分散、难以维护，也掩盖了批量失败的模式。
立即学习“go语言免费学习笔记（深入）”；
- 优先收集所有错误到
[]error，最后用errors.Join()合并返回（Go 1.20+） - 若需区分“部分失败”和“全部失败”，可用计数器 +
errors.Is分类统计，而不是逐个分支处理 - 特别注意：不要在循环里用
return err除非明确要中断整个流程；否则用continue或记录后继续
Unwrap() 的实现方式、以及 defer 捕获时机，这三处最容易出隐蔽问题——尤其是当错误来自第三方库且其 Unwrap() 行为不一致时。 
