错误分支测试需用 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 错误常被丢弃，导致测试漏掉资源泄漏或清理失败场景：
立即学习“go语言免费学习笔记（深入）”；
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 就少一个线上定位噩梦。
