如何使用Golang进行自定义错误的包装与传递_Golang自定义错误包装与传递实践-Golang

Go 1.13+ 中 errors.Wrap 不兼容标准错误链，因其 Unwrap 返回私有结构体，导致 errors.Is/As 失效；应改用 fmt.Errorf(“%w”, err) 或自定义错误类型实现 Unwrap/Is/As。

为什么 errors.Wrap 不能直接用在 Go 1.13+ 的标准错误链里

Go 1.13 引入了 errors.Is 和 errors.As，但它们依赖底层错误是否实现了 Unwrap() 方法。而 github.com/pkg/errors.Wrap 返回的错误类型虽然有 Unwrap()，但它返回的是一个私有结构体，和标准库 fmt.Errorf 的行为不完全兼容——尤其当你混用 pkg/errors 和 fmt.Errorf("%w", err) 时，errors.Is 可能失效。

• 如果你项目已升级到 Go 1.13+，优先用标准库的 fmt.Errorf("%w", err) 包装，不是 errors.Wrap
• pkg/errors 的 Wrap 仍可工作，但无法被 errors.As 正确识别为“包装错误”，除非你手动实现 As 方法
• 老项目迁移时，搜索所有 errors.Wrap 调用，替换为 fmt.Errorf("xxx: %w", err) 更安全

如何让自定义错误支持 Is 和 As 并保留上下文字段

纯包装（%w）只能传递错误链，但很多场景你需要附带结构化信息：如 HTTP 状态码、重试次数、请求 ID。这时不能只靠 fmt.Errorf，得自己实现错误类型。

• 定义结构体时嵌入 error 字段，并实现 Unwrap() 返回它
• 实现 Is(target error) bool 时，先检查自身是否匹配，再调用 errors.Is(wrapped, target)
• 实现 As(target interface{}) bool 时，若目标是指向你自定义类型的指针，就做类型断言赋值；否则继续委托给包裹的错误
• 不要在 Error() 方法里拼接 Unwrap().Error() ——这会破坏错误链的扁平性，fmt.Errorf 已帮你做了

type MyAPIError struct {
    Code    int
    ReqID   string
    Err     error
}

func (e *MyAPIError) Error() string { return fmt.Sprintf("API failed (code=%d, req=%s)", e.Code, e.ReqID) }
func (e *MyAPIError) Unwrap() error  { return e.Err }
func (e *MyAPIError) Is(target error) bool {
    if t, ok := target.(*MyAPIError); ok {
        return e.Code == t.Code && e.ReqID == t.ReqID
    }
    return errors.Is(e.Err, target)
}
func (e *MyAPIError) As(target interface{}) bool {
    if t, ok := target.(*MyAPIError); ok {
        *t = *e
        return true
    }
    return errors.As(e.Err, target)
}

在 HTTP handler 中包装错误时，为什么不能直接 return fmt.Errorf("failed to parse: %w", err)

HTTP handler 通常需要返回特定状态码和 JSON 错误体，但 fmt.Errorf 包装后的错误本身不含状态码语义。如果上层统一用 http.Error 处理，会导致所有错误都变成 500，掩盖了本应是 400 的参数错误。