根本原因是错误链中断：被包装错误未实现Unwrap()、%w参数为nil或非error类型、混用%v/%s导致Unwrap()返回nil，使errors.Is无法穿透查找。
用 fmt.Errorf 的 %w 包裹错误时，为什么 errors.Is 有时不生效？
根本原因不是语法写错，而是被包装的原始错误本身没实现 Error() 方法，或包装层级里混入了非 error 类型（比如 nil、字符串、结构体但没实现接口）。errors.Is 沿着 Unwrap() 链向上找，一旦某层返回 nil 或 panic，链就断了。
常见踩坑点：
-
fmt.Errorf("xxx: %w", nil)—— 直接 panic，因为%w要求右侧必须是error类型 - 自定义错误类型忘了实现
Unwrap() error方法，导致errors.Is到这一层就停住，无法继续往内查 - 用了
%v或%s替代%w，表面看起来像“包装”，实际只是字符串拼接，原始错误被丢弃
errors.As 提取底层错误失败，通常卡在哪几个环节？
errors.As 不是类型断言，它依赖整个错误链中每个节点都正确实现 Unwrap() 并返回合法 error。失败往往不是因为你传错了类型，而是中间某层返回了 nil 或者非指针接收者。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 传给
errors.As的第二个参数必须是指针，例如&pathErr，不能是pathErr - 如果自定义错误嵌套了
error字段，确保该字段名就是Err（或任意名），但Unwrap()方法必须显式返回它 - 调试时可手动展开：用
for err != nil { fmt.Printf("%+v\n", err); err = errors.Unwrap(err) }看链是否完整
要不要在每层都用 %w 包装？过度包裹会带来什么隐性代价？
不是所有错误都需要包裹。包裹的核心目的是传递**上下文 + 可诊断性**，不是堆砌层级。过度包裹会让错误链变长、日志冗余、排查时反而看不清关键路径。
判断标准：
- 调用方需要根据原始错误做决策（比如重试、降级、告警分类）→ 必须用
%w - 只是记录日志或上报监控，且原始错误已含足够信息 → 直接
fmt.Errorf("xxx: %v", err)即可 - 同一函数内多次调用可能出错，但语义相同（如连续读多个配置项）→ 用
errors.Join合并，而非层层%w
注意：errors.Join 是 Go 1.20+ 特性，返回一个能被 errors.Is 和 errors.As 正常处理的复合错误，比手写切片或字符串拼接更可靠。
标准库不带堆栈，那生产环境怎么做到“看到错误就知道在哪一行抛的”？
Go 标准库的 %w 包装本身不记录堆栈，这是设计选择，不是缺陷。要加堆栈，得靠组合手段，且必须明确区分开发和生产场景。
推荐做法：
- 开发阶段：用
github.com/pkg/errors，配合%+v输出，自动注入调用点；但注意它已被社区逐步弃用，仅限临时调试 - 生产阶段：不依赖第三方堆栈库，改用
runtime.Caller在关键入口（如 HTTP handler、gRPC method）捕获一次堆栈，连同错误一起打到结构化日志里 - 真正要追踪跨服务调用链，靠的是 OpenTelemetry 的
Span+TraceID，不是靠单个错误对象里的堆栈行号
最易忽略的一点：无论用哪种方式加堆栈，都别让它出现在 Error() 方法返回的字符串里——这会导致 JSON 序列化失败、日志截断、甚至被某些监控系统误判为异常关键词。
