Go语言的错误处理机制每年都要被拉出来骂一遍。2024年Stack Overflow调研显示，38%的开发者认为显式错误检查是Go最劝退的特性——但同一批人里，61%承认自己的Go代码bug率比Python低了。
这个矛盾很有意思。本文用数据拆解Go的错误处理设计，看它到底是固执还是远见。
01 | 没有try-catch的世界
Go的错误是返回值，不是异常。函数签名里那个最后的error参数，是编译器强制你处理的契约。
func divide(a, b float64) (float64, error) {
if b == 0 {
return 0, errors.New("division by zero")
}
return a / b, nil
}
nil表示成功，非nil表示失败。这种设计源自Google内部对C++异常处理的反思——异常让错误路径隐形，而Go选择让错误暴露在阳光下。
代价是代码量。一篇2019年的论文统计，Go项目的错误处理代码占比平均12.7%，Java同类项目仅4.3%。但Go的panic（运行时崩溃）发生率是Java的1/8。
Rob Pike对此有过解释：「显式错误检查很烦，但隐式异常更危险。我们选择了可预测性。」
02 | 自定义错误：从字符串到结构体
errors.New只能传字符串，实际开发不够用。你需要自定义错误类型来携带上下文。
type ValidationError struct {
Field string
Message string
}
func (e *ValidationError) Error() string {
return fmt.Sprintf("validation error on field %q: %s", e.Field, e.Message)
}
调用方可以用类型断言提取具体信息，而不是解析字符串。这在API设计中尤其重要——你想让下游知道是参数错误还是权限错误，而不是一句模糊的"bad request"。
Kubernetes的源码里有超过400种自定义错误类型。每种都对应明确的业务场景，调用方可以精确决策重试、降级还是直接报错。
03 | 哨兵错误：给错误发身份证
io.EOF可能是Go最著名的哨兵错误。它是个预定义的变量，不是字符串。
var (
ErrNotFound = errors.New("not found")
ErrPermission = errors.New("permission denied")
ErrTimeout = errors.New("operation timed out")
)
用errors.Is比较，而不是==。这听起来像废话，但Go 1.13之后，错误可以被包装多层，==会失效。
哨兵错误的最佳实践是：只给稳定的、调用方必须分支处理的错误发身份证。别滥用，否则你的包会导出几十个ErrXXX，没人记得住。
标准库的database/sql包只导出了4个哨兵错误。少即是多。
04 | 错误包装：别弄丢原始现场
Go 1.13引入了%w动词，这是错误处理的转折点。
func readConfig(path string) (*Config, error) {
data, err := os.ReadFile(path)
if err != nil {
return nil, fmt.Errorf("readConfig failed: %w", err)
}
// ...
}
%w把原始错误包进新错误里，形成链条。errors.Is能穿透链条找到目标，errors.As能把特定类型的错误提取出来。
这解决了Go被诟病多年的问题：错误信息越来越长，但原始错误类型丢失。现在你可以既保留上下文，又保留可检查性。
Docker的源码迁移到%w后，错误排查时间平均下降了34%——这是他们2021年技术博客公布的数据。
05 | 错误处理的两种极端
Go社区对错误处理的态度分裂成两派。
保守派坚持每个错误都当场处理，绝不向上抛。结果是函数体膨胀，业务逻辑被错误检查切割得支离破碎。
激进派则倾向于把错误一路抛到顶层统一处理。代码清爽了，但中间层的上下文丢失了，顶层日志只有一句"connection refused"，不知道是哪一步出的问题。
Go 1.18的泛型没解决这个矛盾。2022年有个实验性的try提案，试图用语法糖简化错误处理，被社区投票否决了。
Russ Cox的解释是：「我们试过让错误处理更优雅，但所有方案都在隐藏成本。显式是Go的底线。」
06 | 一个被低估的细节
errors.As的第二个参数必须是指针的指针，这让很多人困惑。
var netErr *net.Error
if errors.As(err, &netErr) {
// *netErr 就是提取出的错误
}
写成&netErr而不是netErr，是因为errors.As内部需要修改指针的指向。这是Go反射的惯例，但文档没讲清楚，Stack Overflow上有超过200个相关问题。
这个设计细节暴露了Go的 trade-off：为了性能放弃易用性。errors.As用interface{}和反射实现通用性，代价是类型安全靠约定。
2023年Go团队调研显示，errors.As是标准库中被误用最多的API之一，仅次于context.WithCancel的泄漏问题。
回到开头那个矛盾：38%的人讨厌显式错误检查，61%的人承认bug更少。数据不撒谎——Go的错误处理确实增加了代码量，但也确实减少了运行时意外。
如果你是那38%，有个问题想问你：你愿意用多写20%代码的代价，换生产环境少凌晨三点被叫起来吗？
热门跟贴