Go中判断错误是否为自定义类型需用errors.As或类型断言；自定义错误须实现Unwrap()以支持嵌套检查，Error()避免耗时操作，结构化字段（如Code、Retry）提升语义表达。
如何判断错误是否属于某个自定义类型
Go 的错误本质是接口，error 只要求实现 Error() string 方法。要扩展功能（比如添加状态码、重试标记、原始堆栈），必须用自定义结构体实现 error，再通过类型断言或 errors.As 检查具体类型。
常见错误：直接用字符串拼接或 fmt.Errorf 包裹，丢失类型信息，导致无法区分“网络超时”和“参数校验失败”这类语义不同的错误。
- 用
errors.As(err, &target)安全提取底层错误值，比类型断言err.(*MyError)更健壮（能穿透多层包装） - 若需支持多级包装（如
fmt.Errorf("wrap: %w", err)），自定义错误类型必须实现Unwrap() error方法 - 避免在
Error()方法里做耗时操作（如格式化时间、调用外部服务），它可能被日志系统高频调用
怎样给错误附加 HTTP 状态码和重试建议
典型场景是 RPC 或 HTTP 客户端返回错误后，上层需要知道该返回 400 还是 503，是否应重试。这时不能只靠错误文本匹配，而应让错误本身携带结构化元数据。
示例结构：
立即学习“go语言免费学习笔记（深入）”；
type APIError struct {
Code int
Message string
Retry bool
Cause error
}
func (e *APIError) Error() string { return e.Message }
func (e *APIError) Unwrap() error { return e.Cause }
- HTTP 状态码存为
int字段，而非字符串，方便下游 switch 判断 -
Retry字段比检查错误文本中是否含 “timeout” 或 “connection refused” 更可靠 - 若
Cause非空，务必实现Unwrap()，否则errors.Is和errors.As无法穿透到根本原因
为什么 errors.Is 和 errors.As 在嵌套错误中有时失效
失效主因是中间某层错误没实现 Unwrap()，或实现有误（比如始终返回 nil）。Go 的错误链机制依赖显式声明的“可展开性”，不是自动递归解析。
- 用
fmt.Errorf("%w", err)包装时，Go 自动为返回的错误实现Unwrap()；但若手动构造错误且未实现该方法，链就断了 -
errors.Is(err, target)是逐层调用Unwrap()直到 nil，再用==比较；若任一环节返回非预期错误，就会跳过真正目标 - 调试技巧：打印
fmt.Printf("%+v", err)可看到完整错误链（前提是各层都实现了fmt.Formatter）
如何避免错误包装导致内存泄漏或堆栈爆炸
过度包装（尤其是每层都捕获并 fmt.Errorf("%w", err)）会让错误对象携带多份冗余堆栈，且 GC 无法及时回收中间节点。
- 只在语义变化处包装：比如从 “数据库连接失败” 升级为 “用户注册流程失败”，而不是每个函数都包一层
- 避免在循环内反复包装同一错误（如重试逻辑中每次迭代都
fmt.Errorf("retry %d: %w", i, err)） - 若需保留原始堆栈，优先用
runtime/debug.Stack()快照一次，存在字段里，而不是靠层层Unwrap()回溯
错误扩展的关键不在加多少字段，而在确保每一层包装都有明确的语义职责，并且所有中间类型都正确参与错误链协议。漏掉一个 Unwrap()，下游的 errors.As 就可能静默失败。
