热路径中禁用errors.Is高频判断、fmt.Errorf("%w")包装及context.Err()替代业务错误，优先用==比较哨兵错误、轻量包装函数和自定义带字段错误，error channel容量设为1。
热路径里别用 errors.Is 做高频判断
在 QPS 上千甚至上万的请求处理路径（比如 HTTP handler、RPC 入口、核心状态机）中，errors.Is 虽语义清晰，但内部会递归调用 Unwrap 链，每次调用都涉及接口动态 dispatch 和可能的内存分配。实测在 10k QPS 下，对单个错误做 errors.Is(err, os.ErrNotExist) 比直接指针比较慢 3–5 倍。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 若错误来源可控（如同一包内构造），优先用
==比较哨兵变量，如if err == ErrNotFound - 跨模块但需高性能时，导出带方法的错误类型，并用类型断言替代
errors.As：例如if e, ok := err.(*MyAppError); ok && e.Code == CodeNotFound - 绝对避免在循环内或日志打点前无条件调用
errors.Is—— 先判err != nil，再按需判断
fmt.Errorf("%w") 在热路径要节制包装
fmt.Errorf("handle req: %w", err) 看似无害，但在高并发下会触发字符串拼接 + 接口装箱 + 包装结构体分配，实测比直接返回原错误多出约 120ns 开销。当该函数每秒被调用数万次，这部分开销会显著抬升 P99 延迟。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 热路径中，仅在**必须添加不可省略的上下文**时才用
%w，例如记录 traceID 或用户 ID；普通中间层直接return err - 禁用形如
fmt.Errorf("retry %d: %w", n, err)这类带变量插值的包装——数字格式化本身就有开销 - 若需统一加前缀，定义轻量包装函数：
func WithTrace(err error, traceID string) error { return &traceError{err: err, trace: traceID} }，避免 fmt 包依赖
context.Err() 不是业务错误的替代品
常见误写：if ctx.Err() != nil { return ctx.Err() } 然后下游用 errors.Is(err, context.Canceled) 判断。问题在于：ctx.Err() 只能返回 context.Canceled 或 context.DeadlineExceeded，无法携带业务语义（如“库存不足”“余额超限”）。强行复用会导致错误分类混乱、监控指标失真。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 热路径中，
ctx.Err()仅用于快速退出，不作为最终响应错误；真正业务失败仍应返回具体error值 - 不要在 handler 里写
return ctx.Err()后就结束 —— 应区分：取消是外部信号，失败是内部结果 - 若需关联上下文，用字段而非包装：例如自定义错误结构体含
TraceID string字段，而非靠%w套一层
并发场景下 error channel 容量设为 1 就够了
启动多个 goroutine 并行执行任务时，有人习惯建 errCh := make(chan error, len(tasks))。这看似稳妥，但实际造成内存浪费和调度延迟：每个缓冲槽都是 runtime.mspan 分配，且满缓冲会阻塞 sender，违背“快速失败”原则。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 热路径并发任务，用
errCh := make(chan error, 1)即可 —— 只需捕获**首个错误**，后续错误可丢弃（因主流程已失败） - 接收端用
select配合default或超时，避免死等；例如：select { case err := - 若必须收集全部错误，改用
errgroup.Group，它内部用 sync.Pool 复用 error slice，比手动管理 channel 更轻量
热路径错误处理最易被忽略的一点：错误对象本身也是资源。每次 fmt.Errorf、每次 errors.New 都有分配成本，而多数时候你只关心“有没有错”，不是“错的全貌”。先保通路快，再按需补上下文。
