验证错误需分层断言：存在性（err != nil）、身份（errors.Is）、类型（errors.As）、消息（strings.Contains），优先选契约强的层级，避免脆弱匹配。
测试返回错误的函数，核心是验证错误是否符合预期——类型、内容、是否为 nil。Golang 本身不提供内置断言，需结合 if err != nil 判断 + 手动比对，或借助标准库 errors.Is / errors.As 和测试工具（如 testify/assert）提升可读性与健壮性。
基础错误存在性检查
最简方式：调用函数后直接判断 err 是否为 nil，适用于只关心“是否出错”而不深究错误细节的场景。
- ✅ 推荐写法：
if err != nil { t.Fatal("expected no error, got:", err) } - ✅ 反例：
if err == nil { t.Fatal("expected error") }—— 易读性差，建议用if err == nil后接t.Fatal或改用assert.Error - ⚠️ 注意：不要忽略错误变量（如
_, _ := fn()），否则无法验证错误行为
精准匹配预定义错误值
当函数返回的是包级导出的错误变量（如 var ErrNotFound = errors.New("not found")），用 errors.Is 判断是否为同一错误实例（支持嵌套错误链）。
- ✅ 正确示例：
if !errors.Is(err, ErrNotFound) { t.Errorf("expected ErrNotFound, got %v", err) } - ✅ 更简洁（配合 testify）：
assert.ErrorIs(t, err, ErrNotFound) - ❌ 避免
err == ErrNotFound：若错误被fmt.Errorf("wrap: %w", ErrNotFound)包装，该比较会失败
断言错误具体类型或结构
当错误是自定义结构体（如 type ValidationError struct{ Field string }），需用 errors.As 提取底层错误并做类型断言。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- ✅ 安全提取：
var ve *ValidationError; if errors.As(err, &ve) { ... } - ✅ testify 写法：
var ve *ValidationError; assert.True(t, errors.As(err, &ve)) - ⚠️ 不要直接
ve, ok := err.(*ValidationError)：若错误被包装（如fmt.Errorf("%w", ve)），ok为 false
校验错误消息内容（谨慎使用）
仅在错误文本本身是公共契约时（如 CLI 工具面向用户输出），才断言 err.Error() 包含特定字符串；否则应优先用 errors.Is 或 errors.As。
- ✅ 简单包含检查：
if !strings.Contains(err.Error(), "timeout") { ... } - ✅ testify：
assert.Contains(t, err.Error(), "timeout") - ❌ 避免完整字符串相等（
err.Error() == "timeout"）：易受拼写/格式微调影响，脆弱 - ? 提示：可结合正则（
regexp.MatchString）做更灵活匹配，但依然属于弱契约
基本上就这些。关键不是“怎么写断言”，而是“你想验证错误的哪一层契约”——是存在性、身份一致性、类型结构，还是用户可见文案。选对工具，测试才既准确又稳定。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
