如何在Golang中实现跨模块的错误处理_Golang跨模块错误传播与管理

跨模块错误管理需统一用%w包装、在边界添加上下文、解包后断言第三方错误、仅最外层记录日志，否则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>}

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

多个模块都用 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 等兼容库），但生产环境应避免依赖第三方堆栈格式

立即学习“go语言免费学习笔记（深入）”；