Golang错误处理技巧与实践分享

一分耕耘，一分收获！既然打开了这篇文章《Golang错误处理设计技巧分享》，就坚持看下去吧！文中内容包含等等知识点...希望你能在阅读本文后，能真真实实学到知识或者帮你解决心中的疑惑，也欢迎大佬或者新人朋友们多留言评论，多给建议！谢谢！

Go初级项目中绝大多数场景应直接使用内置error接口，仅在需额外字段或特定行为时才自定义错误类型；if err != nil后95%应return err，仅启动失败等不可恢复场景用log.Fatal；错误首次发生处记录日志并%w包装，最外层统一补全上下文；测试需mock依赖错误并用errors.Is/As验证错误处理逻辑。

错误类型该用 error 还是自定义结构体？

Go 初级项目里，绝大多数场景直接用内置的 error 接口就够了。别一上来就写 type MyError struct{...} —— 除非你需要额外字段（比如错误码、请求 ID、重试次数）或要实现特定行为（如 Unwrap() 或 Is() 判断）。标准库的 fmt.Errorf 和 errors.New 足够表达上下文，配合 %w 包装还能保留调用链。

常见错误现象：过早抽象出带字段的错误结构，结果全项目只有 1 处用到；或者每个函数都返回不同结构体，导致上层 switch err.(type) 越写越臃肿。

• 只在需要区分错误语义且影响控制流时才自定义错误类型（例如：网络超时 vs 参数校验失败）
• 用 errors.Is(err, targetErr) 替代类型断言判断是否为某类错误
• 用 errors.As(err, &e) 提取底层错误值，而不是层层断言
• 避免在错误结构体中嵌入业务数据（如用户 ID），容易泄露敏感信息或破坏封装

if err != nil 后该 return 还是 log.Fatal？

95% 的情况应该 return err，把错误交给调用方决定如何处理。只有两种例外：程序启动失败（如配置加载失败、端口被占）、main 函数末尾无法继续运行时，才用 log.Fatal 或 os.Exit(1)。

使用场景差异明显：HTTP handler 里遇到数据库错误，应返回 500 并记录日志，而不是让整个服务崩掉；CLI 工具解析参数失败，可以 fmt.Fprintln(os.Stderr, err); os.Exit(1)，但前提是它真不能继续执行了。

• 绝不在库函数或中间件里调用 log.Fatal —— 这等于替使用者做了终止决策
• 所有可恢复的错误（I/O、网络、校验失败）都向上返回，由最外层（如 HTTP handler、main）统一处理
• 如果用了 log.Fatal，确保它只出现在 main() 或明确的初始化入口，且有清晰注释说明“此处不可恢复”

日志记录和错误传播怎么不重复也不丢失？

核心原则：只在错误首次发生处加日志（含上下文），传播时用 %w 包装，不再重复打日志；最终处理处（如 handler）再统一记录一次，带上 trace ID 或请求路径等现场信息。

容易踩的坑：每个 if err != nil 都跟一句 log.Printf("failed to xxx: %v", err)，结果一个请求失败打出 5 条日志，还全是重复堆栈；或者完全不记录，只返回错误，线上出问题时毫无线索。

• 在错误生成点记录（如 DB 查询失败），用 log.With(...).Errorf("db query failed: %w", err)
• 传播时不记录，只用 fmt.Errorf("calling service Y: %w", err)
• 最外层捕获后，用结构化日志补全请求上下文：

  log.With(zap.String("path", r.URL.Path)).Error("request failed", zap.Error(err))

• 避免用 err.Error() 拼接日志字符串 —— 会丢掉包装链和原始类型信息

测试中怎么验证错误路径是否覆盖到位？

初级项目最容易漏测的是错误分支：只测正常流程，不构造依赖失败来触发 if err != nil 分支。验证重点不是“有没有 return err”，而是“返回的错误是否包含足够信息、能否被正确识别”。

性能影响不大，但逻辑覆盖不到位会导致上线后错误静默或误判。比如 mock 数据库返回 sql.ErrNoRows，但业务代码没用 errors.Is(err, sql.ErrNoRows) 判断，而是直接返回原错误，上层就无法区分“查无结果”和“连接异常”。

• 对每个外部依赖（DB、HTTP client、文件读写）都 mock 其错误返回，至少覆盖 1–2 种典型错误
• 用 errors.Is 或 errors.As 断言错误类型，而不是比较 err.Error() 字符串
• 测试 error 包装链：用 errors.Unwrap 或第三方库（如 github.com/pkg/errors 的 Cause）检查底层错误是否可达
• 避免测试里出现 if err != nil { t.Fatal(err) } —— 这会让测试通过但掩盖错误处理缺陷

真正难的不是写 if err != nil，是想清楚谁该负责处理、要不要暴露细节、日志打在哪一层、测试时能不能逼出那个分支。这些决策一旦定错，后期改起来比加功能还费劲。

以上就是本文的全部内容了，是否有顺利帮助你解决问题？若是能给你带来学习上的帮助，请大家多多支持golang学习网！更多关于Golang的相关知识，也可关注golang学习网公众号。