当前位置：首页 > 文章列表 > Golang > Go教程 > Golang错误处理规范：DaveCheney常量错误观点

Golang错误处理规范：DaveCheney常量错误观点

2026-03-05 13:12:47 0浏览收藏

本文深入解析了Go语言中错误处理的核心规范，重点阐述了Dave Cheney倡导的“常量错误”理念：业务错误应避免使用临时的errors.New("xxx")，而应采用导出的包级变量错误（如var ErrUserNotFound = errors.New("user not found")）或实现Unwrap/Is方法的自定义类型，以确保错误可识别、可比较、可传播；同时厘清了%w与%s包装的本质差异、errors.Is与errors.As的适用边界及常见陷阱，并给出了清晰选型指南——简单哨兵错误优先用导出变量，仅当需携带结构化元信息（如HTTP状态码、SQL错误码）时才引入自定义类型，兼顾简洁性、可维护性与向后兼容性。

Golang错误处理规范_Dave Cheney的“Constant Errors”观点

为什么 `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 追溯。

使用场景：中间件、日志封装、重试逻辑里需要透传底层错误类型时。

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）