fmt.Errorf("%w", err)性能开销极小，仅构造轻量结构体，不分配堆内存、不触发反射或字符串拼接；真正影响性能的是错误链过长、大对象拼接或滥用字符串匹配。
fmt.Errorf("%w", err) 的性能开销几乎可以忽略
直接说结论：fmt.Errorf 用 %w 包装错误，本身不分配额外堆内存（Go 1.20+ 已优化），也不触发反射或字符串拼接；它只是构造一个轻量级结构体，字段为 msg 和 err。实测在百万次调用下，相比裸 return err，耗时差异在纳秒级，GC 压力无可见增长。
真正影响性能的从来不是包装动作本身，而是你包装时干了什么：
- 在循环里反复包装同一个错误（比如每轮重试都
fmt.Errorf("retry %d: %w", i, err)）——错误链被无限拉长，后续errors.Is或errors.As遍历时需逐层Unwrap，时间复杂度从 O(1) 变成 O(n) - 把大对象（如整个 HTTP 请求体、JSON 字符串）塞进错误消息里，比如
fmt.Errorf("failed to process payload %s: %w", string(payload), err)——这会引发大量内存分配和拷贝 - 用
fmt.Sprintf++拼接错误（而非%w），导致原始错误丢失，迫使上层改用字符串匹配（strings.Contains(err.Error(), "...")），既慢又不可靠
errors.Is 和 errors.As 的遍历成本取决于错误链长度
errors.Is 和 errors.As 内部会递归调用 Unwrap，直到找到匹配项或返回 nil。它们有环检测，但没缓存——每次调用都重新遍历。
这意味着：
立即学习“go语言免费学习笔记（深入）”；
- 错误链深度超过 5 层后，
errors.Is(err, os.ErrNotExist)的耗时开始明显上升（尤其在高频路径如 HTTP 中间件） - 如果错误类型实现了自定义
Is方法（如func (e *MyError) Is(target error) bool），它可能提前终止遍历，比依赖标准Unwrap链更高效 -
errors.As在匹配失败时仍要走完整链，而成功时只取第一个匹配项；若你明确知道目标错误总在第 2 层，手动errors.Unwrap(errors.Unwrap(err))可能更快（但不推荐——易出错且破坏可维护性）
什么时候该避免包装？看调用频次和错误来源
不是所有错误都值得包装。高频、底层、确定性的错误，包装反而增加开销且无信息增益：
- 数据库查询返回的
sql.ErrNoRows：它本身已带语义，再包一层fmt.Errorf("user not found: %w", err)对调试帮助极小，却让中间件多一次Is调用 - HTTP handler 中对
json.Unmarshal错误的包装：如果每个请求都解 JSON，且错误率高，包装动作本身虽快，但日志中重复出现“failed to unmarshal request body: invalid character...”会让运维过滤变慢 - 函数内部参数校验失败（如
if id ）：这种错误没有底层原因，用 <code>%w反而误导调用方去Unwrap，应直接用errors.New或fmt.Errorf不带%w
真正在意性能时，优先检查日志和监控链路
线上服务中，错误包装带来的 CPU 或内存开销，远小于日志序列化、网络写入、或 Prometheus 指标打点本身的成本。一个被包装了 3 层的错误，如果最终被 log.Printf("%+v", err) 打印，那格式化动作消耗的资源是包装的百倍以上。
所以实际优化点往往是：
- 关闭 debug 级别日志中的完整错误链打印（例如用
err.Error()替代%+v） - 在中间件统一处理错误时，避免对同一错误反复调用
errors.Is（比如先判断是否为os.ErrNotExist，再判断是否为context.DeadlineExceeded，应合并逻辑） - 自定义错误类型时，若其
Unwrap返回固定值（非动态计算），确保它不触发额外分配——这是最容易被忽略的隐性开销点
