错误分支测试需用 errors.New/fmt.Errorf 创建具名错误变量，通过 errors.Is/errors.As 精确断言；mock 依赖时主动注入预设错误；注意 defer 中 Close 等可能出错的调用；避免字符串匹配错误。

用 errors.New 或 fmt.Errorf 构造可预测的错误值

测试错误分支的前提是让被测函数返回的错误能被稳定识别。直接比较 err == nil 不够，要验证错误类型、消息甚至底层结构。优先用 errors.New 创建具名错误变量，避免每次调用都生成新实例：

var (
    ErrNotFound = errors.New("user not found")
    ErrInvalidID = fmt.Errorf("invalid user id: %w", errors.New("id must be positive"))
)

这样在测试中可用 errors.Is(err, ErrNotFound) 或 errors.As(err, &target) 精确断言，而不是依赖易变的错误字符串。

在 mock 依赖时主动注入错误路径

真实错误往往来自外部调用（如数据库、HTTP 客户端）。测试时不要等它“自然发生”，而是通过接口抽象 + 依赖注入，让 mock 实现直接返回预设错误：

type UserRepository interface {
    GetByID(ctx context.Context, id int) (*User, error)
}

// 测试用 mock
type mockUserRepo struct {
    returnErr error
}

func (m *mockUserRepo) GetByID(ctx context.Context, id int) (*User, error) {
    return nil, m.returnErr
}

// 在测试中：
repo := &mockUserRepo{returnErr: ErrNotFound}
user, err := svc.GetUser(ctx, 123, repo)
if !errors.Is(err, ErrNotFound) {
    t.Fatal("expected ErrNotFound")
}

• 避免在 mock 里写条件逻辑（比如 “当 id==0 时返回错误”），那会让测试行为隐晦且难覆盖边界
• 如果原接口返回的是 *sql.ErrNoRows 这类具体类型，mock 也应返回同类型指针，否则 errors.As 会失败

注意 defer 中的错误被忽略的常见陷阱

很多 Go 函数在 defer 里关闭资源（如 file.Close()），而这些调用也可能返回错误。若主逻辑已出错，defer 错误常被丢弃，导致测试漏掉资源泄漏或清理失败场景：

func processFile(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return err
    }
    defer f.Close() // Close() 可能返回 error，但这里被忽略

    // ... 处理逻辑
    return nil
}

测试这类函数时，不能只检查主错误，还要确保 Close 被调用且其错误被正确处理。可行做法：

• 把 Close 提到显式位置，并在返回前检查：if closeErr := f.Close(); closeErr != nil && err == nil { err = closeErr }
• 或使用包装类型，在 Close 返回非 nil 时 panic（仅限测试环境）以暴露问题

避免用字符串匹配判断错误，除非明确要求

strings.Contains(err.Error(), "timeout") 看似简单，但极易因日志格式调整、翻译、拼写微调而断裂。Go 1.13+ 的错误链机制就是为替代这种脆弱方式而生：

• 用 errors.Is(err, context.DeadlineExceeded) 判断上下文超时，而不是查字符串
• 用 errors.As(err, &os.PathError{}) 检查是否是文件系统错误，而不是匹配 "no such file"
• 只有当错误消息本身就是公开契约（如 CLI 工具输出给用户）时，才考虑字符串断言

错误分支测试最常被忽略的一点：不是“有没有报错”，而是“报的错是否能被上层正确分类和响应”。多一层 errors.Is 或 errors.As 就少一个线上定位噩梦。