errors.unwrap是go 1.13+中用于单步解包错误的函数，仅返回当前错误直接包装的下一层错误，不递归、不自动遍历，需手动循环调用并判空防panic，且返回nil表示链终止而非已达原始错误。
Go 1.13+ 的 errors.Unwrap 是什么，它不等于“获取原始错误”
errors.Unwrap 只返回错误值的直接封装者（即实现 Unwrap() error 方法的那个错误），不是递归找最底层错误。很多人误以为调用一次就能拿到根本原因，结果发现返回 nil 或中间某层就断了。
典型场景：你用 fmt.Errorf("failed: %w", err) 包装错误，或用第三方库（如 github.com/pkg/errors 旧版、go.opentelemetry.io/otel/codes 封装）——这些都可能实现 Unwrap()，但行为不统一。
-
fmt.Errorf包装的错误只支持单层Unwrap()，再调一次就返回nil - 自定义错误类型若没实现
Unwrap()方法，errors.Unwrap永远返回nil - 某些库（如旧版
pkg/errors）返回的是causer接口，和标准库Unwrap不兼容
如何安全地递归解包错误链，直到找到根本原因
标准库不提供递归遍历函数，必须手动循环调用 errors.Unwrap，并配合 errors.Is 或 errors.As 判断目标错误是否存在。
常见错误写法是死循环（比如忘了检查 err == nil）或漏掉最后一层（比如在 Unwrap() 返回 nil 后没检查原 err 是否匹配）。
- 正确模式：用
for err != nil循环，每次检查当前err是否满足条件，再err = errors.Unwrap(err) - 别在循环里直接对
errors.Unwrap(err)的返回值做Is判断——那会跳过当前层 - 如果要提取特定类型（如
*os.PathError），用errors.As(err, &target)在每层尝试，而不是只在顶层调
for err != nil {
if errors.Is(err, os.ErrNotExist) {
return "file missing"
}
if errors.As(err, &pathErr) {
return pathErr.Path
}
err = errors.Unwrap(err)
}
errors.Is 和 errors.As 内部怎么用 Unwrap
这两个函数不是“黑盒”，它们内部就是靠反复调用 errors.Unwrap 实现的，但做了防护：自动处理 nil、避免无限循环（限制最大展开深度，默认 50 层）、跳过不实现 Unwrap() 的错误。
这意味着：如果你自己手写递归逻辑，就得复制这些防护；而直接用 Is/As 更安全，也更符合 Go 错误链设计意图。
-
errors.Is(err, target)会逐层Unwrap，并在每一层调用==或Is()方法比对 -
errors.As(err, &v)同样逐层尝试类型断言或As()方法，一旦成功就停止 - 如果错误链里有环（比如 A.Wrap(B), B.Wrap(A)），
Is/As会因深度限制退出，但手动循环可能卡死
什么时候不该依赖 Unwrap，而该用结构化字段
不是所有错误都适合靠 Unwrap 追溯。比如 HTTP 客户端错误、gRPC 状态码、数据库驱动错误——它们往往把关键信息存在字段里（如 StatusCode、Code()、SQLState），而不是嵌套另一个错误。
强行用 Unwrap 去扒这类错误，容易忽略语义，甚至因封装层级变动导致逻辑失效。
- gRPC 错误应优先用
status.Code(err)，而不是试图Unwrap到status.Status - database/sql 错误建议检查
err.(interface{ Code() string }).Code()或用驱动特有类型断言 - HTTP 错误（如
net/http返回的url.Error）字段Err才是可Unwrap的部分，但Op和URL才是关键上下文
错误链是手段，不是目的；真正重要的是你能可靠提取出决策所需的信息——有时候那个信息就在当前错误的字段里，根本不用拆。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
