根本原因是错误链中断：中间层使用errors.new或字符串拼接替代%w包装，导致某层未实现unwrap()方法，errors.is无法穿透查找。
Go 里没有异常，但错误必须可追溯、可分类、可调试——直接用 errors.New 或 fmt.Errorf 包裹，很快就会在日志里丢掉上下文、分不清是业务错还是系统错、查问题靠猜。
用 fmt.Errorf 带 %w 包装错误时，为什么调用 errors.Is 有时不生效？
根本原因是：只有最内层错误（即被 %w 包裹的那个）实现了 Unwrap() error 方法，而标准库的 fmt.Errorf 确实实现了；但如果你中间用了 errors.New 或字符串拼接再包装，链就断了。
- ✅ 正确：
fmt.Errorf("failed to open file: %w", os.Open(path)) - ❌ 错误：
fmt.Errorf("failed to open file: " + err.Error())—— 完全丢失原始错误类型和Unwrap能力 - ⚠️ 注意：
errors.Is(err, fs.ErrNotExist)只会沿着Unwrap()链向上检查，一旦某层没实现，就终止
定义业务错误类型时，该用自定义结构体还是 errors.New？
取决于是否需要携带额外字段（如错误码、HTTP 状态码、重试建议）或支持动态行为（如 Error() 返回不同格式）。纯标识性错误（如 ErrNotFound）用变量即可；需结构化语义的，必须用结构体。
- 简单标识：
var ErrNotFound = errors.New("not found")—— 轻量，适合内部模块间信号传递 - 结构化业务错误：定义类似
type ValidationError struct { Code string; Field string; Details map[string]string }，并实现Error()和Unwrap()（如果它包装了底层错误） - 别忘了加
Is()方法：比如func (e *ValidationError) Is(target error) bool { return target == ErrValidation }，让errors.Is能识别你的类型
如何统一注入请求 ID、时间戳、函数名等上下文到错误中？
不能靠每次手动 fmt.Errorf("req=%s, at=%v: %w", reqID, time.Now(), err) —— 易漏、难维护、污染业务逻辑。推荐封装一个带上下文的错误包装器，例如 WrapCtx 函数：
func WrapCtx(ctx context.Context, err error, msg string) error {
if err == nil {
return nil
}
reqID := ctx.Value("req_id").(string)
now := time.Now().UTC().Format("2006-01-02T15:04:05Z")
return fmt.Errorf("%s [req=%s, at=%s]: %w", msg, reqID, now, err)
}
- 关键点：只在入口层（如 HTTP handler、gRPC server method）或关键中间件里调用一次，避免层层重复包装
- 别把
context.Context当错误载体传进深层函数——它不是错误上下文，而是取消/超时/值传递机制 - 日志打印时，用
fmt.Printf("%+v", err)才能看到完整堆栈（前提是错误链中至少有一个使用github.com/pkg/errors或 Go 1.17+ 的%w包装）
为什么 errors.As 有时取不到底层错误类型？
常见于你包装了错误但没正确实现 As() 方法。比如自定义错误结构体想支持 errors.As(err, &os.PathError{})，光有 Unwrap() 不够，还得显式实现 As(target interface{}) bool。
- 标准做法：在自定义错误中转发
As到被包装的错误，例如：return errors.As(e.err, target) - 如果自己就是目标类型（比如
*os.PathError），直接return errors.As(e, target)会死循环，要先做类型判断 - 第三方库如
github.com/pkg/errors自动处理了As，但 Go 标准库从 1.17 开始也要求自定义错误自行实现才能被errors.As识别
最易被忽略的是错误类型的“可判定性”——不是所有错误都适合用 errors.Is 判断；当错误携带状态（如重试次数、临时性标记）时，As + 类型断言 + 字段检查才是可靠路径。包装不是目的，让下游能精准响应才是。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
