如何利用Go语言的strings.Contains反模式，通过Error String准确识别Golang中的错误类型？

本文共计1115个文字，预计阅读时间需要5分钟。

Go 的错误处理不是简单的字符串，而是实现了 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。