Golang 从入门到放弃 -0x12

前面我们已经知道 Go 里处理错误的基本姿势是 if err != nil。但真正的项目一复杂，错误就不只是“有或没有”这么简单了。它还牵涉到：错误从哪儿来的、要不要包装、上层怎么判断、该不该暴露给用户。

先从包装错误说起

很多时候你收到一个底层错误，但你还想给它补一点上下文。这个时候 fmt.Errorf 配合 %w 很好用。

func loadConfig(path string) error {
    _, err := os.ReadFile(path)
    if err != nil {
        return fmt.Errorf("read config %s: %w", path, err)
    }
    return nil
}

这样上层看到的就不再只是一个冷冰冰的“file not found”，而是知道“读配置文件的时候出错了”。

errors.Is：判断是不是某类错误

包装了以后，直接拿 == 去比往往就不靠谱了。这时候该用 errors.Is。

if errors.Is(err, os.ErrNotExist) {
    fmt.Println("文件不存在")
}

这很适合判断一些已知哨兵错误。比如文件不存在、超时、上下文取消之类的情况。

errors.As：拿到具体错误类型

如果你定义了自己的错误类型，或者想从一串包装错误里挖出某个具体类型，可以用 errors.As。

type BizError struct {
    Code int
    Msg  string
}

func (e *BizError) Error() string {
    return e.Msg
}

var bizErr *BizError
if errors.As(err, &bizErr) {
    fmt.Println("code:", bizErr.Code)
}

这个场景在 API 服务里很常见。你可能内部一路都在传 error，但到了 HTTP 层想知道它是不是业务错误，是的话回 4xx，不是的话回 500。

自定义错误类型别为了高级而高级

不是每个错误都值得定义一个 struct。很多时候一条 errors.New 或 fmt.Errorf 足够了。真正适合自定义类型的，通常是那些你后面还要根据字段做分支处理的错误。

如果只是想把一句话说完整，那就别把错误设计成论文答辩。

别吞错误

有一种非常危险的代码味道，叫“出错了但假装没看见”。

data, _ := os.ReadFile("config.json")

下划线不是原罪，但别拿它掩耳盗铃。你现在图省的那一秒，未来很可能要用半小时排查来还。

用户看到的错误，和日志里的错误，不一定是一回事

系统内部的错误信息往往很细，适合日志排查；返回给前端或用户的信息，通常要更克制一些。别把数据库连接串、SQL 语句、内部路径一股脑返回出去。

一个比较健康的模式是：

• 日志里记录详细错误和上下文
• 接口里返回简洁、稳定的错误描述

小结

这一章其实是在给错误处理补上“工程味”：

• %w 用来包装错误和保留原始链路。
• errors.Is 判断类别，errors.As 提取类型。
• 不是所有错误都要自定义类型。
• 别为了图快把错误直接吞掉。

下一章我们聊 panic 和 recover。这俩东西不常用，但一旦用错，效果往往很炸裂。