Golang错误处理是否会影响性能
panic/recover 开销远高于普通错误返回，因需栈展开和状态记录，吞吐量可降100倍以上；error接口返回仅指针传递，几乎无成本；defer单次开销纳秒级，但高频滥用会影响性能。
panic/recover 的开销远高于普通错误返回
Go 里用 error 接口返回错误（比如 os.Open 返回 (*File, error)）几乎无运行时成本，只是指针传递和接口赋值。但一旦触发 panic，运行时需展开栈、记录 goroutine 状态、构造调用链，开销是数量级差异。
实测在循环中每轮都 panic 再 recover，吞吐量可能下降 100 倍以上；而正常 if err != nil 判断基本不影响性能。
- panic 是异常控制流，不是错误处理机制——它本就不该用于可预期的失败场景
- HTTP handler 中用
panic捕获空指针然后 recover，看似“兜底”，实际把可控错误变成了高开销路径 - benchmark 时注意：
BenchmarkFoo-8中混入recover会严重污染结果，建议单独测 panic 路径
defer + error 检查本身不拖慢，但 defer 调用次数过多有影响
defer 不是免费的：每次执行都会在当前 goroutine 的 defer 链表上插入一个节点，runtime 需要管理这些延迟调用。但单次 defer 开销极小（纳秒级），真正要注意的是高频小函数里滥用 defer。
func bad() error {
f, err := os.Open("x")
if err != nil {
return err
}
defer f.Close() // 这里没问题
for i := 0; i < 10000; i++ {
defer fmt.Println(i) // 危险：1 万个 defer 节点，内存+调度开销明显
}
return nil
}
- defer 最适合资源清理（文件、锁、数据库连接），不适合替代 if 判断
- go tool compile -gcflags="-m" 可查看编译器是否将 defer 优化为内联（小函数且无闭包时可能）
- goroutine 启动时自带 defer 链表，但大量 defer 仍会增加 GC 扫描压力
errors.Is / errors.As 在 Go 1.13+ 的性能代价很小，但别在热循环里用
errors.Is 和 errors.As 需要遍历错误链（通过 Unwrap()），最坏情况是 O(n) 时间复杂度。不过绝大多数业务错误链很短（1–3 层），实际开销可以忽略。
真正要注意的是：别在 QPS 上万的请求内循环调用它们做条件判断。
- 如果只判断是否是
os.ErrNotExist，直接用err == os.ErrNotExist更快（前提是没被fmt.Errorf包裹） - 自定义错误类型时，实现
Is(error) bool方法可跳过默认遍历逻辑 -
errors.Unwrap(err)单次调用成本低，但反复for err != nil { err = errors.Unwrap(err) }不如用errors.Is
error 字符串拼接和 fmt.Errorf 本身有分配，但通常不构成瓶颈
fmt.Errorf("failed to %s: %w", op, err) 会触发字符串格式化和堆分配，比直接返回原 err 多一次内存分配。但在非高频路径（如初始化、配置加载）里，这点开销无关紧要。
真正在意性能时，可考虑预分配或错误池，但绝大多数服务无需为此优化。
- 避免在日志中间件里对每个请求都
fmt.Errorf("http %d: %w", status, err)—— 直接传原始 error 更
轻量 - 如果错误信息固定，用
var ErrNotFound = errors.New("not found")，零分配 -
errors.Join（Go 1.20+）合并多个 error 会产生新对象，但仅当需要同时暴露多个原因时才用
轻量fmt.Sprint。
