Go如何将多种错误类型统一封装_Go Error统一封装策略

go中统一错误封装的核心是定义含错误码、消息、时间戳、原始错误等字段的自定义appError结构体，实现Error()、Unwrap()、Is()方法，并通过New/Wrap/Wrapf函数统一封装，确保错误可识别、可分类、可追踪。

Go 中统一错误封装的核心是定义自定义错误类型，结合错误码、上下文信息和原始错误链，让错误可识别、可分类、可追踪，而不是简单用 fmt.Errorf 堆叠字符串。

定义结构化错误类型

用 Struct 封装错误，包含错误码、消息、时间戳、调用栈（可选）和原始错误（Unwrap 支持）：

• 错误码建议用 iota 枚举，便于判断和国际化
• 实现 Error() 方法返回用户友好消息
• 实现 Unwrap() 返回底层 err，保持错误链完整
• 可选实现 Is() 或 As() 方便类型断言

示例：

type Code int  const (     CodeOK Code = iota     CodeNotFound     CodeInvalidParam     CodeInternal )  type AppError struct {     Code    Code     Message String     Time    time.Time     Err     error // 原始错误，用于 Unwrap }  func (e *AppError) Error() string {     return e.Message }  func (e *AppError) Unwrap() error { return e.Err }  func (e *AppError) Is(target error) bool {     if t, ok := target.(*AppError); ok {         return e.Code == t.Code     }     return false }

封装错误的常用方式

避免裸写 errors.New 或 fmt.Errorf，统一走封装函数：

• New(code Code, msg string)：新建基础错误（无原始错误）
• Wrap(err error, code Code, msg string)：包装已有错误，保留上下文和原始错误链
• Wrapf(err error, code Code, format string, v...any)：带格式化消息的包装
• 所有函数返回 *AppError，确保类型一致

这样上层可用 errors.Is(err, ErrNotFound) 判断，也可用 errors.As(err, &e) 提取结构体字段。

分层错误处理与日志协同

不同层级职责分明：

• 底层（如 DB、http client）只返回原始错误或简单包装（如 os.PathError）
• 业务层统一用 Wrap 转为 *AppError，补充业务码和语义化消息
• API 层根据错误码映射 HTTP 状态码，并隐藏敏感细节（如不把数据库错误直接透出）
• 日志中间件自动提取 *AppError 的 Code、Message、Time，并记录 stack（若启用了）

例如：DB 查询失败 → 封装为 Wrap(err, CodeNotFound, "user not found") → API 返回 404 + {“code”: “NOT_FOUND”}。

避免常见陷阱

• 不要在封装时丢弃原始错误（即不设 Err 字段），否则丢失调试线索
• 不要用字符串匹配判断错误类型（如 strings.Contains(err.Error(), "timeout")），应靠 errors.Is 或 errors.As
• 不要过度嵌套封装（如 Wrap 三层以上），每层应有明确语义，否则难以定位根因
• 错误码命名建议用大写蛇形（CODE_INVALID_INPUT）或常量组，避免魔法数字

基本上就这些。统一封装不是为了“看起来高级”，而是让错误真正可查、可分、可控 —— 写起来多几行，维护时省半天。