测通错误路径的核心是让依赖返回指定error并验证调用方响应，需接口抽象+可控mock、避免直接赋error、用errors.is/as判断错误、表驱动覆盖多分支、检查副作用，慎用testify/mock。
要测通错误路径，核心不是“让函数出错”，而是“让依赖返回你指定的 error”，再验证调用方是否按预期响应——比如返回该 error、不执行副作用、正确清理资源。
怎么让被测函数返回特定 error
真实 I/O 或网络失败不可控、慢、易飘红，必须替换依赖。关键动作是接口抽象 + 可控返回：
- 把硬依赖（如
*http.Client、*sql.DB）抽成接口，例如type DBQuerier interface { QueryRow(string, ...any) (*sql.Row, error) } - 测试时传入手写 mock 实现，方法体里直接
return nil, sql.ErrNoRows或return nil, errors.New("timeout") - 若第三方库没提供接口（如
time.Sleep），改用函数变量：声明var sleep = time.Sleep，测试前重置为sleep = func(d time.Duration) {}或 panic 版本 - 避免给 struct 字段直接赋 error（如
err: errors.New("boom")），否则无法按输入条件分支返回，覆盖不了多路径逻辑
error 判断为什么不能用 ==
== 只对包级预定义错误变量安全（如 io.EOF、os.ErrNotExist、你自己定义的 var ErrNotFound = errors.New("not found")）。其他情况一律失效：
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 每次
errors.New("xxx")都生成新地址，err == errors.New("not found")永远 false - 用
fmt.Errorf("wrap: %w", io.EOF)包装后，err == io.EOF为 false，但errors.Is(err, io.EOF)为 true - 自定义错误类型需用
errors.As(err, &target)提取，而非靠err.Error()字符串匹配——后者脆弱、易因日志格式变更而断裂
表驱动测试怎么覆盖错误分支
一个函数常有多个错误触发点（空输入、越界 ID、依赖返回 sql.ErrNoRows、context.DeadlineExceeded），表驱动最清晰：
- 每个测试用例含
name（便于定位）、input、mockErr（注入的依赖错误）、wantErrIs（期望匹配的哨兵错误）或wantErrAs（期望的错误类型指针） - 循环中调用被测函数，用
if !errors.Is(err, tc.wantErrIs)断言，或var e *ValidationError; if !errors.As(err, &e)提取字段验证 - 别漏掉“错误发生时是否做了不该做的事”：比如写文件失败，是否仍创建了空文件？是否忘了关闭已打开的句柄？这些需在 mock 中埋点或检查副作用状态
testify/mock 值不值得用
纯 Go 手写 mock 更轻、更透明，适合中等项目；testify/mock 仅在接口巨多且频繁变更时省事，但代价明显：
- 生成的 mock 文件必须
git commit，否则 CI 构建失败 - mock 调用必须显式
mock.AssertExpectations(t)，否则即使没调用也过测试 - mock 返回的 error 类型必须和真实依赖一致（比如返回
sql.ErrNoRows，不是errors.New("no rows")），否则if err == sql.ErrNoRows判断失效 - 小项目引入 testify/mock 反而增加构建步骤和认知负担，手写 3–5 行 mock 实现通常更可靠
最容易被忽略的一点：错误包装链（%w）和错误类型提取（errors.As）必须同步设计——如果你的生产代码用 fmt.Errorf("db fail: %w", err)，测试就必须用 errors.Is 或 errors.As 去穿透，而不是盯着 err.Error() 里的字符串。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
