Go error接口合规实现需用指针接收器：func (e *ValidationError) Error()，以支持errors.As提取、状态共享和扩展；值接收器会导致类型断言失败。
error 接口到底要怎么实现才合规
Go 的 error 接口就一条：必须有 Error() string 方法。但“实现”不等于“能用好”——很多新手返回值接收器（func (e ValidationError) Error()），结果在类型断言时失败，因为 errors.As 或接口赋值要求接收器一致性。
关键点是：只要你想用 errors.As 提取、或通过指针修改错误字段（比如加 traceID）、或让多个错误实例共享状态，就必须用指针接收器：func (e *ValidationError) Error()。标准库里 errors.New 返回的是 *errorString，不是巧合。
- 值接收器 → 类型是
ValidationError，可赋值给error，但errors.As(err, &v)会失败（目标是*ValidationError） - 指针接收器 → 类型是
*ValidationError，errors.As可成功解包，也支持后续扩展（如添加Unwrap() error） - 别混用：同一个类型别一部分方法用值接收器、一部分用指针接收器，会导致接口实现不完整
什么时候该用 errors.New，什么时候必须自定义结构体
errors.New 和 fmt.Errorf 适合“一次性判断”，比如参数校验失败直接返回 ErrInvalidInput 常量；但一旦需要区分错误来源、携带码、支持重试逻辑或日志打点，结构体就是刚需。
典型场景对比：
立即学习“go语言免费学习笔记（深入）”；
- API 层返回 HTTP 400 错误 → 需要
Code字段映射状态码，不能只靠字符串匹配 - 数据库操作失败 → 要区分是约束冲突（
Code=1062）、连接超时（Code=2013）还是语法错误，光靠"failed to exec query"没法做自动化处理 - 微服务间调用 → 错误要透传上下文（
RequestID、TraceID），结构体字段比拼接字符串更安全、更易序列化
反例：var ErrNotFound = errors.New("user not found") 看似简洁，但下游无法知道这是业务未找到，还是缓存穿透，还是 DB 连接失败后伪造的兜底提示。
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
errors.Is 和 errors.As 的真实使用边界
errors.Is 只对「错误相等性」有效，适用于预定义常量（如 ErrNotFound）；errors.As 才是提取结构体错误的正道——但它依赖底层错误链中**存在对应类型的指针实例**。
常见陷阱：
- 包装错误时用了
fmt.Errorf("xxx: %w", err)，但原始err是值类型（ValidationError{}而非&ValidationError{}），errors.As就解不出来 - 多层包装后忘记调用
errors.Unwrap或直接用errors.As——它会自动遍历整个链，但前提是每层都用%w包装且类型一致 - 把
errors.As(err, &e)写成errors.As(err, e)（少取地址），编译能过，运行 panic
实操建议：所有自定义错误类型默认导出指针构造函数，比如 NewValidationError(field, msg) 返回 *ValidationError，避免使用者手写 &ValidationError{...} 出错。
错误包装（%w）不是加日志，而是建链路
用 %w 不是为了让错误信息“看起来更丰富”，而是为构建可追溯的错误链。没有 %w，errors.Is 和 errors.As 就失去意义；滥用 %w（比如每层都包一次但没新增上下文），反而让错误堆栈臃肿难读。
规范做法：
- 底层函数（如 DB 查询）返回原始结构体错误，不包装
- 中间层（如 service）添加领域语义：
return fmt.Errorf("update user profile: %w", err) - 顶层（如 HTTP handler）添加可观测字段：
return fmt.Errorf("http handle update: request_id=%s: %w", reqID, err) - 绝不把
%w当字符串拼接用：fmt.Errorf("failed: %w, detail: %v", err, data)是反模式——data应作为结构体字段加入错误类型，而不是塞进字符串
最容易被忽略的一点：如果你的自定义错误类型实现了 Unwrap() error，那它就正式进入错误链了；没实现，%w 包装后它只是个普通字符串前缀，不会被 errors.As 解包。
