Go错误处理如何避免信息丢失_Go错误上下文设计技巧

不会丢原始错误类型，Errors.Wrap 和 fmt.Errorf(“%w”, err) 均支持 errors.Is/As 穿透，但混用非 %w 包装会破坏类型判断；推荐统一用 %w 并避免 pkg/errors。

go 中用 errors.Wrap 会丢掉原始错误类型吗？

不会丢，但默认行为不保留底层类型断言能力——关键在是否用 errors.WithStack 或 fmt.Errorf("%w", err)。原生 errors.Wrap(err, msg)（来自 github.com/pkg/errors）把原始错误包进新结构体，errors.Is 和 errors.As 仍能穿透多层找到原始错误，前提是没混用标准库 fmt.Errorf 错误构造方式。

常见错误现象：

err := errors.Wrap(io.EOF, "read header failed") if errors.Is(err, io.EOF) { /* 这里能命中 */ }

但换成

err := fmt.Errorf("read header failed: %w", io.EOF) if errors.As(err, &e) { /* e 是 *os.PathError？可能失败，因为 io.EOF 不是 *os.PathError */ }

此时 errors.As 要求目标类型与原始错误完全匹配或可转换，而 fmt.Errorf 的包装不改变底层错误实例。

• 推荐统一用 fmt.Errorf("%w", err)（Go 1.13+），它支持 %w 动词且兼容标准库错误检查函数
• 避免混用 pkg/errors 和标准库错误包装，尤其在跨模块传递时，容易导致 As 失败
• 若需堆栈，用 github.com/go-errors/errors 或自己封装带 StackTrace() 方法的错误类型，而非依赖 pkg/errors（已归档）

如何让日志和监控看到完整错误链而不破坏类型判断？

核心矛盾：日志要可读上下文，监控要精确分类；但加太多描述文字会污染 error.Error() 输出，影响 strings.Contains(err.Error(), "timeout") 这类弱匹配逻辑。

实操建议：

type ContextError struct {     Err    error     Reason string     Code   string // 如 "ERR_DB_CONN_TIMEOUT" } 
func (e *ContextError) Error() string { return fmt.Sprintf("[%s] %s: %v", e.Code, e.Reason, e.Err) }
func (e ContextError) Unwrap() error { return e.Err } func (e ContextError) Is(target error) bool { return errors.Is(e.Err, target) }

这样既保留原始错误的可判断性，又让 log.Printf("failed: %v", err) 输出带上下文的字符串。

• 不要重写 Unwrap() 返回拼接后的字符串错误，否则 errors.Is 穿透失效
• 监控报警规则应基于 Code 字段或自定义方法（如 e.Code()），而非解析 Error() 字符串
• 日志中间件中调用 fmt.Sprintf("%+v", err) 可打印完整链和堆栈（需错误类型实现 fmt.Formatter）

http handler 中怎么透传错误上下文又不暴露敏感信息？

典型场景：数据库查询失败 → 包装为业务错误 → 返回给前端时需隐藏 DB 地址、sql、行号等，但后端日志要保留。

做法是分层构造错误：

// 内部处理层（含敏感上下文） err := fmt.Errorf("db query failed for user %d: %w", userID, pgErr) 
// 转换为对外错误（剥离敏感字段） publicErr := &PublicError{ Message: "service unavailable", Code:    "INTERNAL_ERROR", } log.Error("internal failure", "err", err, "user_id", userID) // 原始 err 记入日志
http.Error(w, publicErr.Error(), http.StatusInternalServerError)

• 永远不在 http.Error 或 jsON 响应体中直接输出 err.Error()
• 用中间结构体（如 PublicError）控制响应内容，字段显式声明，不依赖错误字符串解析
• 如果用 gin/echo，注册全局错误中间件，在 c.Error(err) 后统一做脱敏转换，避免每个 handler 重复写

为什么 errors.Join 在 Go 1.20+ 里不能替代链式包装？

errors.Join 是并列关系，不是嵌套关系——它把多个错误“合并”成一个新错误，但所有子错误处于同一层级，errors.Is 会同时匹配任一成员，无法表达“A 导致 B 导致 C”的因果链。

例如：

err := errors.Join(     fmt.Errorf("failed to open file: %w", os.ErrNotExist),     fmt.Errorf("failed to connect db: %w", context.DeadlineExceeded), ) errors.Is(err, os.ErrNotExist) // true errors.Is(err, context.DeadlineExceeded) // true // 但你无法知道哪个错误是根因，也无法获取调用路径

• Join 适合聚合并发操作中的多个独立失败（如批量上传 3 个文件，2 个失败），不适合单路径错误传播
• 需要因果链时，必须用 %w 单向嵌套，最多一层 Wrap，避免嵌套过深导致堆栈难读
• 超过 3 层嵌套通常说明职责划分有问题，应考虑提前返回或重构错误分类逻辑

实际项目中最容易被忽略的是错误类型的「可测试性」：单元测试里 mock 一个返回 fmt.Errorf("xxx: %w", io.EOF) 的函数，再用 assert.ErrorIs(t, err, io.EOF) 验证，比字符串匹配更可靠；但一旦中间混入 errors.New("xxx") 或非 %w 格式化，整条链就断了。