Golang跨模块错误处理技巧

Golang跨模块错误处理的核心在于构建一条可追溯、可判断、不冗余的错误链：必须统一用`%w`包装错误以保留原始错误链，严格在模块边界（如service层）添加业务上下文而非替换错误，对第三方错误通过循环解包再断言来确保类型判断可靠，并且仅在最外层（如HTTP handler）一次性记录带完整堆栈的日志——任何中间层的错误替换、静默吞没或重复打印都会导致`errors.Is/As`失效、上下文丢失、逻辑分支错判和日志混乱，最终让问题排查变成一场灾难。

错误类型不一致导致跨模块 panic

Go 模块间传递错误时，如果下游模块用 errors.New 或字符串拼接构造错误，上游用 errors.Is/errors.As 判断，大概率失效——因为这些函数只对实现了 Unwrap() 或带包装语义的错误有效。
实操建议：
• 跨模块暴露的错误必须统一用 fmt.Errorf("xxx: %w", err) 包装，保留原始错误链
• 避免在中间层用 errors.New("failed to do X") 替换原始错误
• 若需定义领域错误，用自定义类型实现 error 接口并支持 Unwrap() 方法

模块边界处丢失错误上下文

常见于 HTTP handler 调用 service 层再调用 repository 层：repository 返回 sql.ErrNoRows，service 层没包装就直接返回，handler 无法区分是「查无此用户」还是「数据库连不上」。
实操建议：
• 在模块交接点（如 service 层入口）用 fmt.Errorf("get user %d from db: %w", id, err) 添加上下文
• 不要仅靠错误字符串匹配做逻辑分支（如 strings.Contains(err.Error(), "no rows")），应依赖错误类型或哨兵变量
• 可在 module 根目录定义本模块的哨兵错误，如 var ErrUserNotFound = errors.New("user not found")，并在适当地方用 %w 包装后返回

第三方库错误未适配导致判断失效

比如用 github.com/go-sql-driver/mysql，其错误类型是 *mysql.MySQLError，但直接用 errors.As(err, &mysql.MySQLError{}) 可能失败——因为上游可能已用 %w 包装过，需要多层 Unwrap()。
实操建议：
• 对第三方错误做一次「解包探测」：循环调用 errors.Unwrap() 直到得到非 nil 原始错误，再做类型断言
• 更稳妥的方式是封装一个辅助函数：

func AsMySQL(err error, target *mysql.MySQLError) bool {<br>    for err != nil {<br>        if errors.As(err, target) {<br>            return true<br>        }<br>        err = errors.Unwrap(err)<br>    }<br>    return false<br>}

• 避免在业务逻辑里直接 import 第三方错误类型，应在 infra 层做适配和映射

日志中错误堆栈被截断或重复打印

多个模块都用 log.Printf("err: %v", err)，结果同一错误在日志里出现三次，且没有完整堆栈；或者用了 %+v 但只在最外层 handler 打印，内层 service 又打了一次，造成冗余。
实操建议：
• 错误只在**最外层边界**（如 HTTP handler、CLI command）统一记录，包含完整堆栈：log.Printf("request failed: %+v", err)
• 中间模块禁止单独 log 错误，只负责传播或增强上下文
• 若需调试，可在开发环境开启 errors.StackTrace（需用 github.com/pkg/errors 等兼容库），但生产环境应避免依赖第三方堆栈格式

跨模块错误管理真正的难点不在语法，而在团队对「谁该加上下文」「谁该判断类型」「谁该记录日志」的约定是否一致。一旦某层擅自替换错误、静默吞掉或重复打印，整条链就不可追溯了。

好了，本文到此结束，带大家了解了《Golang跨模块错误处理技巧》，希望本文对你有所帮助！关注golang学习网公众号，给大家分享更多Golang知识！