应保留原有 if err != nil 判断,优先在关键路径用 errors.Is 做语义判断,新错误类型需实现 Unwrap() 以兼容旧 == 比较,老库错误可通过映射或 errors.Join 补救,HTTP 错误响应需统一中间层处理,日志须用 %+v 打印完整错误链。
if err != nil 怎么不动逻辑只升级错误处理?Go 1.20+ 的 errors.Join 和 1.13 引入的 errors.Is/errors.As 并不破坏旧代码——它们只是新增能力,原有 err != nil 判断完全保留。真正要动的是「错误分类」和「错误透传」逻辑,而不是删掉每一处 if。
if err != nil,优先在关键路径(如 HTTP handler、CLI 入口)加 errors.Is(err, fs.ErrNotExist) 做语义判断fmt.Errorf("failed to read %s: %w", path, err) 是安全的,%w 会保留原始错误链,老代码仍能用 == 比对已知错误变量strings.Contains(err.Error(), "timeout"),别急着删——先补上 os.IsTimeout(err) 或自定义 timeout 错误类型,再逐步替换核心原则:新错误必须实现与旧错误相同的判定接口,且不破坏 == 行为。比如你封装了一个 *MyDBError,它应该同时满足:
Unwrap() error 方法,返回底层原始错误(如 sql.ErrNoRows),这样 errors.Is(err, sql.ErrNoRows) 仍为 trueerr == sql.
ErrNoRows,你的新错误就不能直接替代——得用 errors.Is 替换该判断,或让新类型在 Unwrap() 后能抵达原错误fmt.Errorf("db fail: %v", err)(丢失包装),而要用 fmt.Errorf("db fail: %w", err)
func QueryUser(id int) (*User, error) {
row := db.QueryRow("SELECT name FROM users WHERE id = ?", id)
var name string
if err := row.Scan(&name); err != nil {
// ✅ 正确:保留原始 error 链
return nil, fmt.Errorf("query user %d: %w", id, err)
// ❌ 错误:断开 error 链,旧 Is/As 失效
// return nil, fmt.Errorf("query user %d: %v", id, err)
}
return &User{Name: name}, nil
}
%w,怎么补救?很多老库(如早期 github.com/go-sql-driver/mysql 或某些 HTTP 客户端)返回的是纯字符串错误,无法用 %w 包装。这时不能硬加 %w,否则 Unwrap() 返回 nil,errors.Is 失效。可行方案是「错误映射」:
errors.Join 把原始错误和上下文信息合并,至少保留可读性== 判断,可定义一个全局错误变量,并在映射时返回它(但需确保不会误判其他同字符串错误)// 例:将 mysql 驱动的字符串错误映射为语义错误
if strings.Contains(err.Error(), "connection refused") {
return errors.Join(ErrDBConnectionFailed, err)
}
// ErrDBConnectionFailed 是你定义的 var,供 errors.Is 使用
旧客户端可能只看 HTTP 状态码和响应体字符串,新代码却想返回结构化错误(如 {"code":"NOT_FOUND","message":"user not exist"})。关键不是改错误类型,而是统一错误转响应的中间层:
WriteError(w http.ResponseWriter, err error) 函数,在里面用 errors.As 提取业务错误类型,再决定状态码和响应体fmt.Errorf),默认返回 500 + 原始 err.Error(),保证不崩旧客户端http.Error(w, err.Error(), http.StatusInternalServerError) —— 这种写法绕过了所有错误分类逻辑最易被忽略的一点:日志记录错误时,别只打 err.Error()。用 fmt.Sprintf("%+v", err) 才能看到完整错误链和栈帧,这对排查旧代码中层层包装后丢失上下文的问题至关重要。