Go 错误包裹会额外分配堆内存
用 fmt.Errorf 套 %w 或 errors.Join 包裹错误时，Go 会在堆上新建一个错误对象，附带完整的调用栈（如果启用了 errors.WithStack 类似逻辑）或至少复制原错误的字段。这不是零开销操作——尤其在高频出错路径（如网络请求中间件、日志采样点、数据库连接池拒绝场景）里，每秒成千上万次包裹，会明显抬高 GC 压力和分配率。
常见错误现象：pprof heap 显示 runtime.mallocgc 占比突增，且堆对象中大量出现 *fmt.wrapError 或自定义包装类型；go tool trace 中看到密集的 GC 暂停。
- 只在需要传递上下文语义时才包裹：比如把
io.EOF转成 “读取用户配置失败”，而不是每次if err != nil都套一层fmt.Errorf("xxx: %w", err) - 避免在循环内包裹错误：例如遍历 1000 条记录时，每条都
fmt.Errorf("process item %d: %w", i, err)—— 改为最后统一构造一次顶层错误 - 若只需附加字符串信息，且不打算用
errors.Is/errors.As判断底层错误，直接用fmt.Errorf("xxx: %v", err)（注意是%v不是%w），它不会保留原始错误引用，也不触发包裹逻辑
使用 errors.Is / errors.As 会隐式触发错误链遍历
errors.Is 和 errors.As 不是 O(1) 操作。它们会顺着 Unwrap() 链一路向下检查，最坏情况是链长 N 的线性时间。如果错误被多层包裹（比如中间件 A → B → C → 底层 os.PathError），每次调用都要遍历全部层级。
使用场景：HTTP handler 里做错误分类返回不同状态码，或 gRPC server 中映射错误到 codes.Code；这类代码常在关键路径上，被反复执行。
立即学习“go语言免费学习笔记（深入）”；
- 优先用错误变量比较代替
errors.Is：定义包级变量var ErrNotFound = errors.New("not found")，返回时直接return ErrNotFound，检查时用err == ErrNotFound - 如果必须用
errors.Is，确保包裹层数可控（建议 ≤3 层）；避免在 defer 或日志钩子中无条件调用它——日志可能每秒打几百次 - 对性能敏感路径，可提前缓存判断结果：比如在 handler 入口处做一次
isDBErr := errors.Is(err, sql.ErrNoRows)，后续逻辑复用该布尔值
自定义错误类型比 fmt.Errorf 包裹更省内存
用结构体实现 error 接口，字段按需定义（如 Code、TraceID、Retryable bool），能彻底避开 fmt.wrapError 的堆分配和反射开销。它的内存布局紧凑，且可复用实例（比如预创建常见错误变量）。
参数差异：fmt.Errorf 返回的是不可预测的运行时类型，而自定义错误是确定的 struct，编译期可知大小；后者还能加方法支持快速序列化、降级处理等。
- 不要给每个错误都建新 struct：共性大的错误（如各种校验失败）可用同一个
ValidationError，靠Field和Reason字段区分 - 避免在自定义错误里存大对象（如整个 request body、raw bytes），改用 lazy 字段或只存摘要
- 如果需要兼容
%w行为，显式实现Unwrap() error方法即可，但要谨慎评估是否真需要这层链路
大规模服务中错误日志与错误传播要分离
很多人把错误日志和错误返回混在一起：一边用 log.Error("db query failed", "err", err)，一边又 return fmt.Errorf("query user: %w", err)。这导致同一错误被多次包裹、多次记录、多次序列化（尤其用了 zap/slog 的强结构化日志时），内存和 CPU 双重浪费。
性能影响：日志库内部会对 err 调用 fmt.Sprintf("%+v", err)，触发完整错误链展开 + 栈格式化；若此时错误已被包裹过三次，等于做了三轮冗余展开。
- 日志时用
err.Error()或显式提取关键字段（如err.(*MyError).Code），别直接传原始 error 接口 - 传播错误时，只保留业务必需的上下文；非关键信息（如“at handler.go:42”）留给日志，不在错误链里重复携带
- 考虑用中间件统一拦截 panic 和顶层 error，做一次包裹 + 一次日志，而不是每层都 log + return
