Go 的 error 接口判断几乎零开销，真正性能瓶颈在于错误构造时的堆分配；应复用预定义错误变量、避免循环内 fmt.Errorf、慎用 panic 替代错误返回。
Go 的 error 接口本身几乎没有性能开销
很多人一看到 if err != nil 就担心分支预测失败或内存分配，其实 error 是个接口类型，但绝大多数时候你返回的是 nil 或一个预先定义好的错误变量（比如 io.EOF），这时底层只是指针比较，几乎零成本。
真正吃性能的是构造错误的那一刻——尤其是用 fmt.Errorf 拼接字符串、或者调用 errors.New 创建新对象。每次调用都会分配堆内存。
- 高频路径（如网络包解析、循环读取）里避免在循环内用
fmt.Errorf("failed at %d: %w", i, err) - 可复用的错误尽量提前定义为包级变量：
var ErrInvalidHeader = errors.New("invalid header") - 需要携带上下文又不想分配？用
errors.Join（Go 1.20+）比嵌套fmt.Errorf更轻量，但注意它仍会分配
不要用 panic 替代错误返回来“提升性能”
有人觉得 “panic 跳出深调用栈比层层 return err 快”，这是典型误解。抛出 panic 的开销远高于正常错误返回：要捕获 goroutine 栈、构建运行时信息、触发 defer 链——在压测中常比 return err 慢 10–100 倍。
而且 recover 不是免费的，它会阻止编译器做某些优化，还容易掩盖真实问题。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
-
panic只该用于程序无法继续的致命状态（如配置加载失败、数据库连接池初始化失败），不是错误处理机制 - HTTP handler 里用
panic捕获 500 错误？可以，但别指望它提速；反而可能因 recover 不及时导致 goroutine 泄漏 - 单元测试里用
panic断言？不如直接assert.Error(t, err)清晰可靠
高性能场景下如何减少错误分配和判断开销
当你的函数每秒调用百万次，且错误率极低（比如 sync.Pool.Get 失败概率
常见做法不是去掉错误检查，而是换一种更紧凑的表达方式。
- 用布尔返回值 + 隐式错误变量（仅限内部工具函数）：
ok := json.Unmarshal(data, &v); if !ok { return fmt.Errorf("parse failed") }—— 这省了接口动态派发，但牺牲了错误细节 - 批量操作时聚合错误：
errors.Join(err1, err2, err3)比三次return fmt.Errorf("step1: %w; step2: %w", err1, err2)少一次格式化开销 - 对已知固定错误码的系统（如 Redis 协议响应），直接用整数错误码 + 查表映射，绕过
error接口，但需自行维护一致性
Go 1.20+ 的 errors.Is 和 errors.As 有明显性能代价
这两个函数为了支持任意嵌套的错误链，会递归遍历 Unwrap() 链。哪怕链长只有 3 层，在热点路径里也比直接类型断言慢 3–5 倍。
如果你确定错误来源可控（比如只来自某几个包），优先用类型断言或指针比较。
- 代替
errors.Is(err, io.EOF)：直接写err == io.EOF（因为io.EOF是变量，不是每次 new 出来的） - 代替
errors.As(err, &e)：如果知道错误类型是*json.SyntaxError，直接e, ok := err.(*json.SyntaxError) - 只有当你必须兼容第三方库返回的任意包装错误时，才用
Is/As，并接受那点开销
fmt.Errorf，可能省下几纳秒；但多一层 errors.Is 嵌套，可能让 p99 延迟跳变。这些数字不显眼，堆在一起就成瓶颈。 
