Go测试中判断错误需聚焦“错得对不对”：用errors.Is匹配预定义错误值（支持包装链），errors.As提取自定义错误类型，避免err==nil或err.Error()字符串比较，并通过接口抽象+mock确保错误路径可复现。
Go 测试中判断错误返回，核心不是“有没有错”，而是“错得对不对”——即错误类型、包装链、语义是否匹配预期。直接用 err == nil 或 err.Error() == "xxx" 会漏掉包装错误、脆弱且难维护。
用 errors.Is 判断预定义错误值（含包装链）
当你导出一个包级错误变量（如 var ErrNotFound = errors.New("not found")），测试时必须用 errors.Is，它能穿透 fmt.Errorf("wrap: %w", err) 多层包装找到原始错误。
- ✅ 正确：
if !errors.Is(err, ErrNotFound) { t.Fatalf("expected ErrNotFound, got %v", err) } - ❌ 错误：
err == ErrNotFound—— 一旦被%w包装就失效 - ⚠️ 注意：仅适用于
errors.New或fmt.Errorf创建的错误值，不适用于每次新建的errors.New("xxx")临时错误
用 errors.As 提取并断言自定义错误类型
若错误是结构体（如 *ValidationError），需用 errors.As 安全提取，它能处理嵌套包装，比直接类型断言更鲁棒。
- ✅ 正确：
var ve *ValidationError
if errors.As(err, &ve) {
if ve.Field != "email" {
t.Errorf("expected Field=email, got %s", ve.Field)
}
} - ❌ 错误：
ve, ok := err.(*ValidationError)—— 若错误是fmt.Errorf("bad input: %w", ve)，ok为false - ? 提示：
errors.As第二个参数必须是指针地址（&ve），否则无法写入
避免直接比对 err.Error() 字符串
除非错误消息是面向用户的稳定契约（如 CLI 工具输出），否则不应依赖完整字符串相等。拼写微调、空格增减都会让测试脆性爆炸。
- ✅ 可接受（弱校验）：
strings.Contains(err.Error(), "timeout") - ❌ 高危（禁止）：
err.Error() == "i/o timeout"—— 标准库版本升级可能改成"I/O timeout" - ? 替代思路：优先用
errors.Is(err, context.DeadlineExceeded)或net.ErrClosed等标准错误变量
测试前必须构造可复现的错误路径
错误测试失效，90% 是因为没真正触发错误。不能靠“运气”让数据库连不上，而要主动注入失败逻辑。
- ✅ 推荐方式：接口抽象 + mock 返回错误
type Reader interface { ReadFile(string) ([]byte, error) }
// 测试时传入：
mockReader := &mockReader{err: fs.ErrNotExist}
result, err := Process(mockReader, "config.json") - ❌ 常见陷阱：测试中调用真实
os.ReadFile("nonexistent.txt")—— 依赖文件系统状态，CI 易失败 - ⚠️ 关键点：确保被测函数确实执行到了你期望报错的那一行，加日志或断点验证路径是否进入
最常被忽略的其实是错误包装本身——如果生产代码里忘了用 %w，上层 errors.Is 就永远找不到原始错误，测试看似通过，实则掩盖了故障定位能力的缺失。
