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语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
-
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()
