go自定义错误必须实现首字母大写的无参error()方法返回string，接收者建议用指针以避免状态丢失；error()仅用于展示，类型断言和errors.is/as才支撑多态处理。
Go 里自定义 Error() 方法必须实现 error 接口
Go 的错误处理依赖鸭子类型：只要类型实现了 Error() 方法，返回 string，它就被视为 error。不是继承，也不是显式声明 implements，而是编译器自动识别签名匹配。
常见错误现象：cannot use &MyErr{} as error in return statement: *MyErr does not implement error (missing Error method)——多半是方法名拼错（比如写成 Errorf 或 error 小写），或签名不对（参数不为空、返回非 string）。
-
Error()必须是无参、返回string的方法，大小写敏感，首字母大写 - 接收者建议用指针（
func (e *MyErr) Error() string），否则值拷贝可能丢失字段状态（比如含切片或 map 的错误） - 如果错误结构体含可变字段（如时间戳、请求 ID），值接收者会返回旧快照，容易误判
带上下文的自定义错误要避免字符串拼接陷阱
很多人直接在 Error() 里用 fmt.Sprintf 拼接字段，看似简单，但会丢失原始数据结构，后续无法做类型断言或字段提取。
使用场景：需要记录 HTTP 状态码、数据库错误码、重试次数等，且上层逻辑需根据这些值做分支处理（比如只对 status == 429 退避）。
立即学习“go语言免费学习笔记（深入）”；
- 不要写
return fmt.Sprintf("failed with code %d", e.Code)—— 这把Code“烤”进字符串了 - 应该保留字段可访问性，让调用方能
if e, ok := err.(*HTTPError); ok { handle(e.Code) } - 若真要加上下文（如日志中显示 traceID），可用
fmt.Errorf("trace %s: %w", traceID, originalErr)包装，而不是覆盖Error()
用 %w 包装错误时，Error() 不再是唯一出口
Go 1.13 引入的错误包装机制让 Error() 只负责“展示”，而错误链的展开、检查、解包交给 errors.Is 和 errors.As。这时候自定义类型的 Error() 只影响 fmt.Print 类输出，不影响逻辑判断。
性能影响：每次调用 errors.As 都要遍历错误链，如果链过长（>5 层），可能成为瓶颈；兼容性上，老代码若用 == 或 strings.Contains(err.Error(), "...") 判断，会失效。
- 包装错误时，原错误的
Error()仍会被调用，但新包装器的Error()通常只返回摘要（如"database timeout"） - 想支持
errors.As，必须确保被包装的错误是接口类型（如error字段），且自己不屏蔽底层错误 - 别在包装器里重写
Error()去拼接所有嵌套信息——那会让日志冗长，也违背“展示 vs 结构”的分离原则
多态错误处理的关键是类型断言，不是 Error() 返回值
所谓“多态”，在 Go 里实际靠运行时类型检查：errors.As(err, &target) 或 target, ok := err.(*MyError)。这和 Error() 的返回内容完全无关——哪怕你返回空字符串，只要类型匹配，断言就成功。
容易踩的坑：有人以为给 Error() 返回不同字符串就能触发不同分支，结果发现 switch err.Error() 在真实环境极不可靠（比如网络错误消息随系统 locale 变化，或中间件重写了错误文本）。
- 分支逻辑必须基于类型或错误码字段，而非字符串内容
- 多个自定义错误类型共用同一父结构（如嵌入
BaseError）时，注意字段名冲突和内存对齐 - 导出字段（首字母大写）才可在包外被断言访问；未导出字段需提供 Getter 方法，否则外部无法读取
最常被忽略的一点：错误值比较用 errors.Is，不是 ==；类型提取用 errors.As，不是强制类型转换。前者能穿透包装，后者能安全解包——这两个函数才是 Go 错误多态的真正支点。
