Go语言错误处理全攻略

Go语言的错误处理强调显式、可追溯与责任分明：必须逐层检查每个可能失败的操作，用%w包装错误以保留完整错误链，自定义错误需嵌入底层error以支持类型断言和结构化处理，同时坚决避免用panic替代可预期错误的正常返回——错误不是异常，而是驱动业务逻辑、重试策略、HTTP状态码乃至系统熔断的核心一等公民，写错一处包装或忽略一次检查，都可能让问题在生产环境隐匿数日难以定位。

用 if err != nil 检查每一个可能失败的操作

Go 不会自动跳过错误，也不会隐式抛出异常。你写的每一行可能返回 error 的调用，都得显式检查——这不是冗余，是责任边界。忽略它，等于把崩溃留给下游或用户。

• 常见错误现象：在 os.Open、json.Unmarshal、http.Do 后没检查 err，导致后续 panic 或静默失败
• 不要写 _, err := doSomething(); if err != nil { ... }，除非你真不需要返回值；否则容易漏掉关键数据
• 避免在循环里只打印日志却不返回或中断——比如批量处理文件时，一个失败不该让全部静默跳过
• 初始化阶段（如 main 函数开头）可用 log.Fatal，但服务运行中应返回错误并由上层决定重试、降级或返回 HTTP 500

用 %w 包装错误，别丢原始错误链

从 Go 1.13 起，fmt.Errorf("xxx: %w", err) 是加上下文的唯一推荐方式。它保留了原始错误的类型和值，让 errors.Is 和 errors.As 能正常工作。用 %v 或字符串拼接就等于自断诊断路径。

• 错误示例：return errors.New("config load failed: " + err.Error()) → 原始 os.ErrNotExist 信息丢失，无法用 errors.Is(err, os.ErrNotExist) 判断
• 正确写法：return fmt.Errorf("loading config: %w", err)
• 包装层级不宜过深——3 层以内较合理；超过后调试成本陡增，不如重构逻辑或提前分类
• errors.Unwrap 只在必要时手动调用（比如日志脱敏），日常判断一律用 errors.Is / errors.As

定义自定义错误类型时，优先实现 Error() 并嵌入原始 error

当需要区分业务错误（如参数校验失败、权限不足）或携带结构化字段（如 Field、Code）时，结构体错误比字符串更可靠。但别忘了把底层错误存进去，否则又断链了。

• 推荐结构：type ValidationError struct { Field string; Msg string; Err error }，并在 Error() 方法里组合输出
• 这样既支持 errors.As(err, &e) 提取字段，也能用 errors.Unwrap(e) 拿到原始错误
• 避免只存字符串：Msg string 而不存 Err error，会导致无法追溯 I/O 或网络错误源头
• HTTP 服务中可据此映射状态码：if errors.As(err, &validationErr) { http.Error(w, validationErr.Msg, http.StatusBadRequest) }

别用 panic 处理可预期错误

panic 是给不可恢复的编程错误用的，比如空指针解引用、数组越界、断言失败。把它当成“高级 return err”是最大误区——它破坏调用栈、难测试、掩盖真实错误类型。

• 典型滥用场景：数据库查询返回 sql.ErrNoRows 时 panic，而不是用 errors.Is(err, sql.ErrNoRows) 分支处理
• recover 只应在最外层入口（如 HTTP handler、goroutine 启动函数）做兜底，且必须配合日志记录原始 panic 值
• 单元测试中遇到 panic 必须用 defer recover() 捕获，否则测试直接失败；而普通 error 可直接断言，简洁可靠
• 标准库几乎不用 panic 处理业务错误——json.Unmarshal 返回 error，time.Parse 返回 error，这才是 Go 的一致性

最容易被忽略的一点：错误不是日志，也不是通知。它是一等公民返回值，要参与控制流、影响重试策略、决定 HTTP 状态码、甚至驱动熔断。写错一行 %w，可能让运维查三天日志都找不到原始磁盘满错误。

理论要掌握，实操不能落！以上关于《Go语言错误处理全攻略》的详细介绍，大家都掌握了吧！如果想要继续提升自己的能力，那么就来关注golang学习网公众号吧！