错误包装和处理需避免高频分配与栈捕获：循环内禁用errors.Wrap，优先用预定义错误或%w；用errors.Is/As替代字符串匹配和类型断言；defer recover仅用于panic而非业务错误；日志慎用%+v，改用err.Error()或结构化字段。
错误包装开销大，fmt.Errorf 和 errors.Wrap 不是免费的
每次调用 fmt.Errorf 或 errors.Wrap 都会分配堆内存、拼接字符串、捕获调用栈（尤其 errors.Wrap 默认调用 runtime.Caller），在高频路径（如网络请求循环、数据库批量操作）中会显著拖慢吞吐量。
- 避免在 hot path 中反复包装错误：比如 for 循环内每轮都
errors.Wrap(err, "failed to process item") - 若只需标识错误类型，优先用自定义错误值（
var ErrNotFound = errors.New("not found")），零分配 - 需要上下文但不需完整栈时，用
fmt.Errorf("%w", err)（Go 1.13+）替代errors.Wrap，它不捕获栈帧 - 真要保留栈且高频，考虑用
github.com/pkg/errors的WithMessage（不捕获新栈）代替Wrap
用 errors.Is 和 errors.As 替代字符串匹配或类型断言
旧式写法如 strings.Contains(err.Error(), "timeout") 或 e, ok := err.(*net.OpError) 不仅脆弱（易被包装层遮蔽），而且每次调用 err.Error() 都触发字符串构造，type assertion 在多层包装下常失败。
-
errors.Is(err, context.DeadlineExceeded)可穿透任意层数的%w包装，无额外分配 -
errors.As(err, &e)能安全提取底层具体错误类型，比手动断言更健壮 - 确保你包装错误时用了
%w（不是%s），否则Is/As无法向下传递
不要在 defer 中无条件调用 recover() 处理业务错误
用 defer + recover() 捕获 panic 是合理场景，但把它当成“通用错误兜底”来处理可预期的业务错误（如参数校验失败、HTTP 状态码非 2xx），不仅语义错位，还会带来明显性能损耗：每个 defer 都有注册开销，recover 触发时需遍历 goroutine 栈。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- panic/recover 应只用于真正异常情况（如不可恢复的协程状态损坏），而非 HTTP 请求返回
404这类常规流程 - 把错误检查放在显式控制流里：
if err != nil { return err }，这是零成本的分支判断 - 若封装了带错误返回的函数，别在 caller 里再 defer recover —— 这会让调用链失去错误来源和堆栈线索
日志错误时慎用 fmt.Sprintf("%+v", err)
%+v 会强制展开整个错误链并打印完整调用栈，对 github.com/pkg/errors 或 errors.Join 类型的错误，可能生成数 KB 字符串，且涉及多次内存分配和反射调用，在高并发日志场景下极易成为瓶颈。
- 生产环境记录错误，优先用
err.Error()（只取顶层消息）或结构化字段如"err": err.Error(), "err_type": fmt.Sprintf("%T", err) - 若必须查栈，限定在 debug 级别，并加采样（如每千次打一次完整栈）
- 使用
zap或zerolog等高性能日志库时，它们对error类型有专门优化，但依然建议显式传zap.Error(err)而非zap.String("err", fmt.Sprintf("%+v", err))
实际压测中，一个每秒处理 5k 请求的服务，把循环内 errors.Wrap 改为预定义错误变量后，P99 延迟下降约 12%；而误用 %+v 打印错误导致 GC 压力上升，使内存占用峰值翻倍。这些点不在语法层面报错，但会在流量上来时突然暴露。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
