应避免用 strings.contains(err.error(), ...) 判断错误类型，因其破坏类型安全、易受文案变更和关键词冲突影响；应优先使用 errors.is 或 errors.as 进行类型安全的错误识别与提取。
用 strings.Contains 判断错误类型是错的
Go 的错误不是字符串，而是实现了 Error() 方法的接口。把 err.Error() 当成原始日志去模糊匹配，等于放弃类型安全，也绕过了 Go 错误处理的设计意图。
常见错误现象：strings.Contains(err.Error(), "timeout") 看似能捕获超时，但一旦底层库改了错误文案（比如从 "i/o timeout" 变成 "context deadline exceeded"），逻辑就 silently 失效；更糟的是，不同错误可能共享关键词（比如两个 unrelated 错误都含 "invalid"），导致误判。
- 永远别在生产代码里用
strings.Contains(err.Error(), ...)做控制流分支 - 如果上游库没导出错误变量或类型，说明它不鼓励你做这种判断——优先查文档，看是否支持
errors.Is或errors.As - 临时调试可以打日志看
err.Error()，但上线前必须替换掉
errors.Is 和 errors.As 怎么选
两者都基于错误链（error wrapping），但语义不同：errors.Is 用于判断是否等于某个**已知错误值**（比如 io.EOF）；errors.As 用于提取某个**错误类型实例**（比如提取 *url.Error 或自定义的 *MyTimeoutError）。
使用场景举例：HTTP 客户端返回错误，你想区分是网络不可达、TLS 握手失败，还是服务端返回了 5xx —— 前两者通常可被 errors.As 提取具体类型，而 5xx 属于业务响应，不属于 error 接口范畴，不该在这里处理。
立即学习“go语言免费学习笔记（深入）”；
- 匹配预定义错误常量（如
os.ErrNotExist、io.EOF）→ 用errors.Is(err, os.ErrNotExist) - 需要访问错误内部字段（如
URL、Timeout字段）→ 用errors.As(err, &target) - 不确定上游是否 wrap 过错误？两个函数都自动遍历错误链，不用手动
cause或Unwrap
自己定义错误类型时必须导出变量或结构体
如果你写一个包，又希望别人能可靠识别你的错误，光实现 Error() 方法远远不够。必须提供可比较的错误变量，或可断言的公开类型。
反例：return fmt.Errorf("failed to connect: %w", netErr) —— 调用方无法稳定识别，只能退化回字符串匹配。
- 推荐做法一（简单场景）：
var ErrConnectionFailed = errors.New("connection failed")，然后用errors.Is(err, ErrConnectionFailed) - 推荐做法二（需携带上下文）：
type ConnectionError struct{ Addr string; Timeout bool }，并确保ConnectionError是 public 类型，再用errors.As(err, &e) - 切记：不要把错误类型设为 unexported（首字母小写），否则外部包无法 import 和断言
第三方库错误不支持 errors.Is/As 怎么办
不是所有库都按 Go 1.13+ 错误标准设计。比如老版本 github.com/go-sql-driver/mysql 返回的错误是私有结构体，且没导出类型或变量；golang.org/x/net/context（已归档）的 timeout 错误曾长期只靠字符串描述。
此时没有优雅解法，只能降级处理，但要加显式注释和 TODO：
- 先尝试
errors.Is/errors.As，失败再 fallback 到字符串检查（仅限已知稳定文案，如"context deadline exceeded"） - 在字符串匹配前加
// TODO: upgrade mysql driver to v1.7+ and use mysql.MySQLError - 避免对多语言环境敏感的文案（如带中文、空格变化、标点差异），只匹配核心标识符（如
"timeout"单独出现风险高，"deadline exceeded"更稳妥）
真正麻烦的不是写 fallback，而是没人维护这些注释 —— 三个月后没人记得为什么这里有个 strings.Contains。
