Go errors包仅支持基础错误创建，错误链、堆栈和上下文需用fmt.Errorf配合%w包装；errors.New适用于静态无参错误（如包级常量），fmt.Errorf用于格式化、变量插入或错误包装；errors.Is和errors.As仅对%w包装的错误有效，手动errors.Unwrap极少使用，因Is/As已自动递归处理错误链。
Go 的 errors 包本身不支持错误链、堆栈或上下文注入——它只提供最基础的错误创建能力，真正可用的错误处理要靠 errors（Go 1.13+）和 x/errors（已归档）的组合，或直接用标准库 fmt.Errorf 配合 %w。
什么时候该用 errors.New 而不是 fmt.Errorf
当错误是静态、无参数、不需携带额外信息时，errors.New 更轻量且可比较；一旦需要格式化字符串、插入变量或包装底层错误，就必须用 fmt.Errorf。
-
errors.New("connection timeout")可用于定义包级常量错误，比如var ErrTimeout = errors.New("timeout") -
fmt.Errorf("read %s: %w", filename, io.ErrUnexpectedEOF)才能实现错误包装（wrap），支持后续用errors.Is或errors.As判断 - 直接拼接字符串（如
"read " + filename + ": " + err.Error()）会丢失原始错误类型，无法 unwrap
errors.Is 和 errors.As 的实际使用边界
这两个函数只对用 %w 包装过的错误有效，对纯字符串错误（包括 errors.New 创建后又被 fmt.Sprintf 拼接过）完全无效。
-
errors.Is(err, io.EOF)成立的前提是：err 是由fmt.Errorf("... %w", io.EOF)构造的，或本身就是io.EOF -
errors.As(err, &target)要求target是指针，且 err 或其任意一层 wrapped error 实现了与*target相同的接口或类型 - 若中间某层用了
fmt.Errorf("%v", innerErr)（没用%w），链就断了，Is/As将跳过该层
为什么 errors.Unwrap 很少手动调用
errors.Unwrap 是底层机制，日常开发几乎不需要直接调用——errors.Is 和 errors.As 已自动递归遍历整个错误链；手动 Unwrap 容易漏掉多层嵌套，还可能引发 panic（当传入 nil 或非 wrapping 错误时）。
立即学习“go语言免费学习笔记（深入）”；
- 错误链可能是多层的：
fmt.Errorf("http: %w", fmt.Errorf("json: %w", io.ErrUnexpectedEOF))，errors.Is会完整检查所有层级 - 手动循环
Unwrap不仅冗余，还会绕过标准库对自定义Unwrap() error方法的统一处理逻辑 - 只有在极少数需要精确控制展开深度（比如日志脱敏只取前两层）时才考虑手动调用
真正容易被忽略的是：错误包装不是越多越好。过度嵌套（比如每层都 fmt.Errorf("step X: %w", err)）会让错误消息冗长、难以定位根因，也增加 As 匹配失败概率——关键在于在哪一层做 wrap，而不是无差别地 wrap 每一次返回。
