*customError 能赋值给 error 接口是因为它隐式实现了 error() 方法；若仅指针实现，则值类型不能直接使用；errors.is/as 依赖动态类型信息，需传入正确类型的实例或地址。
为什么 *CustomError 不等于 error 类型但能赋值给它
因为 go 的接口是隐式实现的：error 是一个只含 Error() 方法的接口，只要某个类型（哪怕是指针类型）实现了这个方法，它就满足 error 接口。所以 *CustomError 能直接返回，不是因为“指针特殊”，而是因为它实现了方法；而 CustomError 值类型如果没实现，就不能用。
常见错误现象：return CustomError{msg: "x"} 编译失败，报 cannot use ... (type CustomError) as type error —— 就是因为你只给 *CustomError 实现了 Error()，没给值类型实现。
- 推荐统一用指针实现：
func (e *CustomError) Error() String，避免值类型意外逃逸或复制开销 - 如果同时支持值/指针调用，得额外给值类型也实现：
func (e CustomError) Error() string，但通常没必要 - 注意：
fmt.Errorf("wrap: %w", err)中的%w要求err是error接口，*CustomError没问题，但nil *CustomError传进去会变成非 nil 的error，这点容易被忽略
errors.Is 和 errors.As 对 *CustomError 的行为差异
这两个函数底层依赖接口的动态类型信息，不是靠值比较。它们能正确识别 *CustomError，但前提是错误链里确实存的是该指针类型，而不是被中间某层转成了其他 error（比如 fmt.Errorf("%w", err) 后再包装）。
使用场景：你想判断某个错误是否是自定义类型，或者想提取其中的字段做日志/重试逻辑。
立即学习“go语言免费学习笔记（深入）”；
-
errors.As(err, &target)要求target是*CustomError类型的变量地址，不能传CustomError{}或nil -
errors.Is(err, &CustomError{})写法是错的 ——&CustomError{}是临时指针，类型是*CustomError，但errors.Is比较的是具体值，应该用errors.Is(err, myErr)，其中myErr是包级变量或已构造好的实例 - 性能影响：每次
errors.As都要反射检查类型，高频路径慎用；可先用errors.Is快速判断是否是同一类错误
什么时候该返回 *CustomError，而不是 fmt.Errorf 或 errors.New
核心判断标准：是否需要携带结构化信息（如 code、traceID、重试策略），或是否需要被下游精确识别和处理。纯字符串错误（比如 “file not found”）用 errors.New 更轻量；带上下文的错误链建议用 fmt.Errorf + %w；只有需要下游做类型断言、字段提取、或统一监控上报时，才值得定义 *CustomError。
- 别为了“看起来专业”而堆砌自定义错误 —— 多数 http handler 里
return fmt.Errorf("failed to parse json: %w", err)就够了 - 如果错误只在本包内使用，且无外部依赖，优先用未导出的
*customError，避免暴露实现细节 - 兼容性注意：Go 1.13+ 的错误链机制对
*CustomError完全友好，但老版本（%w，此时若用了包装，下游errors.Unwrap可能拿不到原始*CustomError
nil *CustomError 的陷阱：它不是 nil error
这是最常踩的坑：var e *CustomError 是 nil 指针，但把它直接 return，Go 会自动转成 error 接口，此时接口的动态类型是 *CustomError，动态值是 nil —— 所以整个接口不为 nil！if err != nil 判断会失败，但 errors.As(err, &e) 却能成功，只是解出来是 nil 指针。
- 正确写法永远是：
return (*CustomError)(nil)或更清晰地写成return &CustomError{...}/return nil（当你要返回空 error） - 构造函数里别写
return &CustomError{}然后忘记填字段，否则err.Error()可能 panic 或返回空字符串 - 测试时别只测
err != nil，还要测errors.As(err, &e)后e是否非 nil —— 尤其在中间件或封装层
类型断言和错误包装的组合很容易掩盖 nil 指针问题，上线后可能表现为“错误没被正确捕获”或“日志里看不到预期字段”，查起来要翻好几层调用栈。