Golang中的错误模式设计_Golang错误模式的应用与实践

go中Error是接口而非异常，需显式处理；应优先用errors.New/fmt.Errorf，自定义错误必实现Error()方法；用errors.Is/errors.As替代字符串匹配；业务错误应具名化、语义化；ctx.Err()等系统错误不可盲目包装。

Go 中的 error 类型本质是接口，不是异常

Go 不支持 try/catch，error 是一个内置接口：type error Interface { Error() String }。这意味着任何实现了 Error() 方法的类型都能当错误用，但**它不携带堆栈、不自动传播、不隐式中断控制流**。你写的 if err != nil 不是语法糖，是显式分支判断——这直接决定了错误处理必须写在调用点附近，没法“集中捕获”。

常见误用：有人试图用 panic 模拟异常，结果导致程序崩溃或 recover 难以覆盖；也有人把所有错误都包装成自定义结构体却忘了实现 Error() 方法，导致 fmt.Println(err) 输出 &{...} 而非可读字符串。

• 永远优先用 errors.New() 或 fmt.Errorf() 构造基础错误，除非你需要额外字段（如码、时间、上下文）
• 自定义错误类型务必实现 Error() string，且返回值应包含足够诊断信息，不要只返回 "failed"
• 避免在库函数中随意 panic；若必须，应在文档里明确标注“此函数 panic 的条件”，否则调用方无法防御

使用 errors.Is 和 errors.As 判断错误类型而非字符串匹配

早期 Go 程序常写 strings.Contains(err.Error(), "timeout") 或 err.Error() == "connection refused"，这种写法脆弱：一换错误消息就失效，国际化时更崩。Go 1.13 引入的 errors.Is() 和 errors.As() 才是正确姿势——它们基于错误链（wrapped error）做语义判断。

比如 os.Open 在路径不存在时返回 *os.PathError，它包装了底层 syscall.errno，而 syscall.ENOENT 实现了 error 接口。这时 errors.Is(err, fs.ErrNotExist) 才可靠，因为 fs.ErrNotExist 是一个预定义变量，不是字符串。

立即学习“go语言免费学习笔记（深入）”；

• errors.Is(err, target) 用于判断是否等于某个已知错误变量（如 io.EOF、fs.ErrNotExist）
• errors.As(err, &target) 用于提取底层具体错误类型，例如想拿到 *os.PathError 中的 Op 或 Path 字段
• 自己包装错误时，务必用 fmt.Errorf("read header: %w", err)，其中 %w 是关键——没有它，errors.Is 和 errors.As 就断链了

业务错误应区分领域语义，避免全用 fmt.Errorf 包装

一个支付服务返回 "payment failed: rpc timeout" 和 "payment failed: insufficient balance"，前端需要据此展示不同提示、触发不同重试逻辑。如果都用 fmt.Errorf 打平成字符串，下游只能靠解析文本——这违背了类型安全和可维护性。

推荐做法：为关键业务错误定义具名类型，实现 error 接口，并提供访问方法。例如：

type InsufficientBalanceError struct {     AccountID string     Balance   float64 }  func (e *InsufficientBalanceError) Error() string {     return "insufficient balance" }  func (e *InsufficientBalanceError) IsInsufficientBalance() bool {     return true }

这样调用方可安全地用 errors.As(err, &e) 提取结构体，再读取 e.Balance 做决策。

• 不要把 http 状态码、数据库错误码直接塞进 fmt.Errorf 消息里；它们应映射为业务错误类型
• 错误类型名要体现领域含义（如 InvalidOrderStateError），而不是技术细节（如 jsONMarshalError）
• 日志记录错误时，用 fmt.printf("failed to process order %s: %+v", orderID, err)，%+v 能展开 wrapped error 链，比 %v 更有用

ctx.Err() 和超时错误需单独处理，别混进业务 error 链

Go 的上下文取消机制会通过 ctx.Err() 返回 context.Canceled 或 context.DeadlineExceeded。这类错误代表“操作被外部中断”，不是业务失败。如果把它和业务错误一起用 %w 包装（如 fmt.Errorf("send notification: %w", ctx.Err())），会导致 errors.Is(err, context.DeadlineExceeded) 失败——因为包装后原始错误被藏在了内部。

正确做法是：在函数出口处统一检查 ctx.Err()，并优先返回它；或者在错误包装前先判断是否为上下文错误，若是则直接返回，不包装。

• 所有接受 context.Context 的函数，第一件事应该是 select { case ，而不是等到底层 IO 才发现超时
• 不要把 ctx.Err() 当作普通错误传给 fmt.Errorf(... %w)；它属于控制流信号，不是业务域错误
• 测试超时场景时，用 context.WithTimeout(context.Background(), 1*time.Nanosecond)，确保能稳定触发 ctx.Err()

错误链的深度、上下文的剥离、业务语义与控制信号的边界——这些地方不写代码看不出来，一上线就暴露。