应使用 errors.Is 和 errors.As 判断错误类型，因其支持多层包装；自定义错误需实现 Unwrap 方法；日志应保留错误链，HTTP 错误需按语义映射状态码。
用 errors.Is 和 errors.As 判断错误类型，别用 == 或 strings.Contains
Go 的错误是值，不是类型，直接比较 err == io.EOF 看似可行，但一旦中间层包装了错误（比如用 fmt.Errorf("read failed: %w", err)），原始错误就被包进去了，== 就失效。同理，靠字符串匹配既脆弱又慢，还容易漏掉大小写或空格变化。
正确做法是用标准库提供的语义化判断：
-
errors.Is(err, io.EOF)检查是否「是」某个底层错误（支持多层包装） -
errors.As(err, &target)尝试把错误解包成具体类型（比如自定义错误结构体），用于提取上下文字段
示例：
if errors.Is(err, os.ErrNotExist) {
log.Printf("config file missing, using defaults")
return defaultConfig, nil
}
var pathErr *os.PathError
if errors.As(err, &pathErr) {
log.Printf("failed on path: %s, op: %s", pathErr.Path, pathErr.Op)
}
自定义错误要实现 Unwrap 方法，否则 errors.Is/As 失效
如果你写了带额外字段的错误类型（比如含 Code、TraceID 的错误），又希望它能被 errors.Is 或 errors.As 正确识别，就必须显式实现 Unwrap() error 方法，返回被包装的下一层错误。
常见错误写法是只嵌入 error 字段却不实现 Unwrap，导致外层错误无法穿透：
- ✅ 正确：
type AppError struct { Code int Message string Err error // 底层错误 } func (e *AppError) Error() string { return e.Message } func (e *AppError) Unwrap() error { return e.Err } - ❌ 错误：漏掉
Unwrap，errors.Is(err, io.EOF)对*AppError总是返回false
不要在日志里只打 err.Error()，丢失错误链和类型信息
调用 log.Printf("failed: %v", err) 时，如果 err 是包装过的（比如 fmt.Errorf("handle request: %w", io.EOF)），默认 %v 只输出最外层消息，底层错误和调用链全丢了。调试时根本看不出是哪一层出的问题。
