Go中统一错误封装的核心是定义含错误码、消息、时间戳、原始错误等字段的自定义AppError结构体，实现Error()、Unwrap()、Is()方法，并通过New/Wrap/Wrapf函数统一封装，确保错误可识别、可分类、可追踪。
Go 中统一错误封装的核心是定义自定义错误类型，结合错误码、上下文信息和原始错误链，让错误可识别、可分类、可追踪，而不是简单用 fmt.Errorf 堆叠字符串。
定义结构化错误类型
用 struct 封装错误，包含错误码、消息、时间戳、调用栈（可选）和原始错误（Unwrap 支持）：
错误码建议用 iota 枚举，便于判断和国际化 实现 Error() 方法返回用户友好消息 实现 Unwrap() 返回底层 err，保持错误链完整 可选实现 Is() 或 As() 方便类型断言
示例：
type Code intconst ( 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）或常量组，避免魔法数字
基本上就这些。统一封装不是为了“看起来高级”，而是让错误真正可查、可分、可控 —— 写起来多几行，维护时省半天。
以上就是Go如何将多种错误类型统一封装_Go Error统一封装策略的详细内容，更多请关注创想鸟其它相关文章！
版权声明：本文内容由互联网用户自发贡献，该文观点仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。
如发现本站有涉嫌抄袭侵权/违法违规的内容， 请发送邮件至 chuangxiangniao@163.com 举报，一经查实，本站将立刻删除。
发布者：程序猿，转转请注明出处：https://www.chuangxiangniao.com/p/1428544.html
微信扫一扫 
支付宝扫一扫 
