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 会产生新对象，但仅当需要同时暴露多个原因时才用

实际压测中，Go 错误处理本身极少成为性能瓶颈；真正拖慢服务的，往往是错误发生后没及时返回、导致后续无意义计算，或者把错误日志打在 hot path 里反复调用 fmt.Sprint。