Errors.new(“xxx”) 不适合业务错误判断，因其生成的错误是不可比较的独立指针，应改用导出的包级变量错误（如var errusernotfound = errors.new(“user not found”)）或实现unwrap/is方法的自定义类型。
为什么 errors.New("xxx") 不适合业务错误判断
Dave Cheney 认为，用 errors.New 创建的字符串错误本质是“一次性快照”，无法被稳定识别或区分。比如两个地方都写了 errors.New("user not found")，你没法靠 == 或 errors.Is 安全判断——它们是不同地址的指针，即使内容一样也不相等。
常见错误现象：if err == errors.New("user not found") 永远为 false；或者用 strings.Contains(err.Error(), "not found") 做判断，结果一改错误文案就挂。
- 业务错误应该用自定义类型（如
type UserNotFoundErr Struct{}）实现Error()方法 - 或者直接定义包级变量错误：
var ErrUserNotFound = errors.New("user not found")，然后统一复用这个变量 - go 1.13+ 推荐用
errors.Is(err, ErrUserNotFound)判断，它支持包装链（fmt.Errorf("wrap: %w", ErrUserNotFound)）
什么时候该用 %w 而不是 %s 包装错误
用 %w 是为了保留原始错误的“可识别性”；用 %s 就等于把错误降级成纯文本，后续再也无法用 errors.Is 或 errors.As 追溯。
使用场景：中间件、日志封装、重试逻辑里需要透传底层错误类型时。
立即学习“go语言免费学习笔记（深入）”；
-
return fmt.Errorf("failed to fetch user: %w", db.ErrNotFound)✅ 可被errors.Is(err, db.ErrNotFound)捕获 -
return fmt.Errorf("failed to fetch user: %s", db.ErrNotFound)❌ 原始错误丢失，只剩字符串 - 注意：只有最后一个
%w会被errors.Unwrap解出，多个%w会覆盖，不推荐
errors.Is 和 errors.As 的实际边界在哪
errors.Is 查的是“是否等于某个错误值”，适合判断预定义的哨兵错误（如 io.EOF、os.ErrNotExist）；errors.As 查的是“是否能转成某类错误类型”，适合需要访问错误内部字段的场景（比如想读取 http 状态码或数据库错误码）。
容易踩的坑：对自定义错误类型没实现 Unwrap() error 方法，errors.As 就无法向下穿透到被包装的底层错误。
- 如果错误链里有
MyDBError{Code: 1062}，且它实现了Unwrap() error返回底层mysql.MySQLError，那errors.As(err, &target)才可能成功 -
errors.Is(err, io.EOF)在fmt.Errorf("read failed: %w", io.EOF)后依然返回 true - 别对
nil错误调用errors.Is或errors.As，它们会 panic（虽然 Go 1.20+ 已修复，但旧版本仍需 guard）
包级变量错误 vs 自定义错误类型：怎么选
包级变量（var ErrInvalidID = errors.New("invalid id")）够用就别上结构体。Dave Cheney 强调：**多数业务错误不需要携带状态，只需要可识别、可测试、可传播**。
性能影响几乎为零，但可维护性差别很大——变量错误写法简单、测试易 mock、导出清晰；而结构体错误一旦暴露字段，就等于承诺了 API 兼容性。
- 用变量错误：权限拒绝、参数校验失败、资源未找到等无上下文依赖的错误
- 用自定义类型：需要附带 HTTP 状态码、SQL 错误码、重试建议等元信息时（记得实现
Unwrap()和Is()方法） - 避免在错误类型里放指针或 map 字段——序列化、日志打印、跨 goroutine 传递都可能出问题
最常被忽略的一点：错误变量必须导出（首字母大写），否则其他包根本没法用 errors.Is(err, mypkg.ErrNotFound) 判断。