Golang错误处理与代码解耦的关系

Go 的 error 接口设计天然支持解耦，通过行为契约而非具体实现实现模块间松耦合；自定义错误应包装底层错误、避免裸指针比较、结构化字段需封装访问；errors.As 应限于边界层且封装为语义化函数；panic/recover 仅用于启动失败等意外场景，业务错误须走 error 链路；各层只处理自身可决策的错误，其余原样透传并保留错误链。

Go 的 error 类型本身就是解耦的接口

Go 不强制要求 panic 或继承异常类，error 是一个只含 Error() string 方法的接口。这意味着任何包都可以定义自己的错误类型，只要实现该方法，就能和标准库、其他模块无缝协作——不依赖具体实现，只依赖行为契约。

这种设计天然支持解耦：业务逻辑层无需 import 数据库或 HTTP 包，也能接收并处理它们返回的 error；调用方只关心“出错了”，不关心“谁抛的错”。

• 自定义错误建议用 fmt.Errorf 套 %w 包装底层错误，保留栈信息（如 fmt.Errorf("failed to open file: %w", err)）
• 避免直接比较 err == io.EOF 这类裸指针判断，改用 errors.Is(err, io.EOF) —— 它能穿透多层包装，更健壮
• 若需携带结构化字段（如错误码、请求 ID），定义带字段的 struct 并实现 Error() 方法，但别暴露内部字段给调用方，否则又耦合了

使用 errors.As 提取特定错误类型会破坏解耦吗？

会，但必要时可控。比如你依赖某个外部 SDK 返回了 *http.ResponseError，而你需要读取它的 StatusCode 字段做重试决策——这时必须用 errors.As(err, &target) 把错误“还原”成具体类型。

关键在于：这个提取动作应严格限制在最靠近错误源头的边界层（如 adapter 层或 client 封装层），绝不让业务逻辑层直接调用 errors.As 去解析下游错误。

• 把 errors.As 封装进一个函数，比如 IsRateLimited(err)，对外只暴露语义化判断，隐藏底层类型
• 如果多个地方都需要提取同一类错误，说明你可能漏掉了一层抽象——考虑定义统一的错误分类接口（如 Temporary() bool），由各错误类型自行实现
• 过度使用 errors.As 会让测试变脆弱：一旦下游错误类型变更（哪怕只是重命名 struct），你的提取逻辑就失效

defer + recover 不该用于常规错误处理

Go 中 panic/recover 是为真正意外场景（如空指针解引用、无限递归）准备的，不是 try/catch 的替代品。把它用在 HTTP handler 里捕获数据库超时，等于把控制流错误伪装成异常，反而加重耦合。

因为 recover 会强制你在调用栈某一层“拦截并消化” panic，这层必须知道所有可能 panic 的路径，也就被迫依赖了那些本该被隔离的组件。

• HTTP handler 应该用 if err != nil { return err } 向上返回，由统一中间件（如 func(http.Handler) http.Handler）做错误转 HTTP 状态码
• 数据库操作中遇到 context.DeadlineExceeded，应该原样返回，而不是 recover 后转成自定义错误——上层按需处理即可
• 唯一合理用 recover 的地方是程序启动阶段（如初始化全局连接池失败），防止整个服务起不来；运行时业务错误一律走 error 链路

错误处理代码写在哪，决定了耦合程度

错误不该在数据访问层（DAO）里被“消化”掉。例如 DAO 函数返回 nil, nil 表示“没查到数据”，看似简化了调用方，实则抹杀了“是真没数据，还是 DB 连接失败”的区别，迫使上层无法区分处理。

真正的解耦，是让每一层只处理自己能决策的错误，其余原样透传。

• DAO 层：只做 SQL 执行，错误全量返回（包括 sql.ErrNoRows）；不判断“是不是预期为空”，那是 service 层的事
• Service 层：收到 sql.ErrNoRows 可转成业务错误 user.NotFoundError，但要保留原始错误（%w），方便日志追踪
• API 层：只负责把 user.NotFoundError 映射成 HTTP 404，不碰数据库错误细节

func (s *UserService) GetByID(id int) (*User, error) {
    u, err := s.repo.FindByID(id)
    if err != nil {
        if errors.Is(err, sql.ErrNoRows) {
            return nil, &user.NotFoundError{ID: id}
        }
        return nil, fmt.Errorf("failed to query user: %w", err)
    }
    return u, nil
}

错误链越长，责任越清晰。怕的是在 repo 里写 if err != nil { log.Fatal(err) }——这等于把日志、监控、恢复策略全焊死在数据层。