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