热路径应避免 fmt.Errorf 包装错误以减少堆分配；改用轻量 WrappedError 结构体仅存上下文标识，延迟到边界层统一格式化。必须用时仅限出口点，禁用冗余描述，透传已知固定错误。
热路径上用 fmt.Errorf("%w", err) 包装错误，会触发堆分配——这不是错，是设计使然；但高频调用时它真会成为性能瓶颈。
为什么 fmt.Errorf 在热路径上分配内存
每次调用 fmt.Errorf 都会新建一个 *fmt.wrapError 结构体（Go 1.20+ 是 errors.errorString + 包装字段），并复制原始错误的字符串和上下文。这个结构体必然逃逸到堆上——无论你传入的是 error 还是 *AppError。
- 用
go build -gcflags="-m"编译就能看到类似wrapError escapes to heap的提示 - 即使错误本身是栈上小结构体（如
struct{ code string; msg string }），包装后也得堆分配 - HTTP handler 每秒处理几千请求时，这可能带来数万次额外堆分配，推高 GC 压力
热路径该用什么替代 fmt.Errorf
不是不用错误包装，而是换一种不分配的方式传递上下文。核心思路：把“包装动作”下沉到真正需要日志或序列化的边界层，热路径只做轻量标记。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 定义轻量错误类型，比如
type WrappedError struct { Err error; Context string }，实现Error()和Unwrap()，但不拼接字符串——Context字段只存 key 或 code（如"db_query"） - 在热路径中直接返回
&WrappedError{Err: orig, Context: "cache_miss"}—— 这个结构体很小（两个指针），若生命周期可控，可能不逃逸 - 顶层 handler 或中间件统一做一次格式化：
log.Printf("failed %s: %v", e.Context, e.Err)，此时才触发字符串拼接 - 避免在每层都调用
fmt.Errorf，尤其不要在 for 循环或高频回调里包装
什么时候必须用 fmt.Errorf，以及怎么减损
某些场景绕不开 fmt.Errorf：比如你要注入动态值（fmt.Errorf("timeout after %dms: %w", dur.Milliseconds(), err)）。这时只能接受分配，但可以控制频率和范围。
立即学习“go语言免费学习笔记（深入）”；
- 仅在明确“出口点”使用，例如 HTTP handler 返回前、gRPC 方法末尾
- 禁用
fmt.Errorf中的冗余字段：不重复写 “failed to”，原始错误本身已含语义；用 code 替代长描述（"ERR_CACHE_MISS"而非"failed to fetch from cache"） - 如果错误链只用于调试，考虑用
runtime.Caller手动记录位置，而非靠包装堆叠——后者开销更大 - 对已知固定错误（如
io.EOF、context.Canceled），跳过包装，直接透传
真正难的不是选哪个函数，而是判断哪一层算“热”、哪一层算“边界”。一个 cache.Get 调用可能每秒发生十万次，但它不该自己记录“cache miss”，而应让上层业务决定是否要包装和上报——否则你优化了分配，却埋下了语义污染的坑。
