Go单元测试验证error的核心是检查是否为nil、是否为预期类型、是否匹配预期错误；优先用errors.Is和errors.As，避免字符串比较。
在 Go 单元测试中验证 error 是否正确，核心是：检查 error 是否为 nil、是否为预期类型、是否包含预期内容。不推荐用字符串比较（脆弱），应优先用类型断言 + 错误判等标准方式。
检查 error 是否为 nil 或非 nil
这是最基础也最容易出错的一步。很多测试只关注“成功路径”，却忽略对错误路径的显式校验。
- 期望函数成功 → error 应为 nil
- 期望函数失败 → error 应 非 nil，且需进一步验证其性质
示例：
AI舌诊面诊问诊医疗系统+诊疗商城系统源码
下载
AI 舌诊面诊问诊医疗系统 + 诊疗商城系统源码是一套结合 AI 辅助诊断与商品转化的健康类程序，基于浩创云、ThinkPHP（PHP）开发，支持微信服务号与 H5 端，适合做中医舌诊面诊问答、健康建议推送以及配套诊疗商品的运营。
err := doSomething()
if err != nil {
t.Fatal("expected no error, got:", err)
}
用 errors.Is 判断底层错误是否匹配
适用于包装错误（如 fmt.Errorf("wrap: %w", err) 或 errors.Wrap）场景，能穿透多层包装找到原始错误。
- 使用
errors.Is(err, targetErr)判断是否等于某个已知错误变量（如io.EOF、自定义包级变量ErrNotFound） - 避免硬编码字符串，也不依赖错误的完整文本
示例：
var ErrNotFound = errors.New("not found")
func TestFetchUser(t *testing.T) {
_, err := FetchUser(999)
if !errors.Is(err, ErrNotFound) {
t.Fatalf("expected ErrNotFound, got %v", err)
}
}
用 errors.As 断言错误类型（含自定义错误）
当需要访问错误的结构体字段（比如 HTTP 状态码、错误码 code、详情 message）时，必须用 errors.As 做类型断言。
- 适用于实现了 error 接口的自定义结构体错误
- 比直接用
err.(*MyError)更安全（自动处理包装）
示例：
type ValidationError struct {
Code int
Message string
}
func (e *ValidationError) Error() string { return e.Message }
// 测试中：
var ve *ValidationError
if errors.As(err, &ve) {
if ve.Code != 400 {
t.Errorf("expected code 400, got %d", ve.Code)
}
} else {
t.Error("error is not *ValidationError")
}
避免字符串匹配 error.Error()
虽然简单，但极易因格式微调（空格、标点、翻译）导致测试失败，属于反模式。
- 除非是临时调试或测试第三方库（无源码控制）
- 永远不要用
strings.Contains(err.Error(), "not found")做主断言
如果真要检查消息片段，至少配合 errors.Is 或 errors.As 先确认错误身份，再谨慎校验消息 —— 但依然建议把可校验的语义信息（如 code、kind）提成字段。
基本上就这些。关键是把错误当作一等公民来设计和测试：导出可比较的错误变量、定义可断言的错误类型、少依赖字符串输出。不复杂但容易忽略。
