通过预定义错误、延迟检查、defer-recover和适度包装，减少Go中高频路径的错误处理开销，提升性能与可读性。
在Go语言开发中，错误处理是日常编码的重要部分。虽然
if err != nil模式清晰直接，但在高频路径或性能敏感场景下，频繁的错误检查可能带来一定开销。通过合理设计和编码技巧，可以有效减少错误检查的负担，提升代码可读性和执行效率。
避免在热路径中频繁返回错误
在性能关键的循环或高频调用函数中，连续的错误判断会增加分支预测失败和函数调用开销。如果错误发生概率极低，可考虑将错误检查延迟或合并处理。
例如，在批量处理数据时，可先执行操作，仅在出现错误时中断：
- 使用标志位记录是否出错，循环结束后统一处理
- 对非致命错误先记录，最后汇总返回
- 避免在每次迭代中调用
fmt.Errorf
等开销较大的操作
利用defer和panic/recover处理罕见错误
对于极少见的错误场景（如配置解析、初始化），可结合
defer和
recover避免层层传递错误。这种方式适合错误无法恢复但发生概率极低的情况。
立即学习“go语言免费学习笔记（深入）”；
注意：不推荐用于常规流程控制，仅适用于初始化或顶层错误兜底。
- 在
main
或init
中使用defer recover()
捕获意外 - 避免在库函数中滥用panic，破坏调用方错误处理逻辑
- 确保recover后能安全退出或记录日志
错误分类与预定义错误减少分配
频繁创建错误实例（如
errors.New或
fmt.Errorf）会增加内存分配。对于固定错误类型，应使用预定义变量复用错误对象。
示例：
var ErrNotFound = errors.New("not found")
var ErrTimeout = errors.New("request timeout")
这样比较错误时可直接用
==而非
errors.Is，提升性能。
使用错误包装的适度原则
Go 1.13+支持
%w格式包装错误，但过度包装会增加堆栈深度和解析成本。只在需要透传并添加上下文时才包装。
- 避免在每一层都用
fmt.Errorf("failed: %w", err) - 选择性地在关键边界（如API入口、模块交互）添加上下文
- 使用
errors.Is
和errors.As
进行解包判断，而非字符串匹配
基本上就这些。关键是在清晰性和性能之间找到平衡，不为小收益牺牲可维护性。错误处理优化不是消除检查，而是 smarter 的处理。
