Go测试中应通过接口隔离实现错误注入：将依赖抽象为接口，测试时用mock返回指定error；避免硬编码错误、panic替代error，注意errors.Is进行包装后error比较。
Go测试中如何用接口隔离实现错误注入
直接在被测函数里硬编码错误不可控，也不利于单元测试。核心思路是把可能出错的依赖（如数据库、HTTP客户端、文件操作）抽象为接口，测试时用 mock 实现该接口并主动返回 error。
例如，一个依赖 io.Reader 读取配置的函数，不要直接传 *os.File，而是接收 io.Reader 接口：
func LoadConfig(r io.Reader) (Config, error) {
data, err := io.ReadAll(r)
if err != nil {
return Config{}, err // 这里就能被控制
}
// ...
}
测试时传入自定义结构体：
type errReader struct{ err error }
func (e errReader) Read(p []byte) (n int, err error) { return 0, e.err }
t.Run("returns error on read failure", func(t *testing.T) {
_, err := LoadConfig(errReader{errors.New("read timeout")})
if !errors.Is(err, context.DeadlineExceeded) {
t.Fatal("expected deadline error")
}
})
使用 testify/mock 或 gomock 模拟带错误的方法调用
当依赖是结构体方法（比如 *http.Client.Do 或自定义服务的 Send()），需要生成 mock 类型。推荐 gomock（官方维护）或 testify/mock（轻量）。
立即学习“go语言免费学习笔记（深入）”；
关键点不是“怎么生成 mock”，而是「如何让 mock 方法返回指定 error」：
-
gomock中用Return(nil, errors.New("network failed")) -
testify/mock中用.Return(nil, errors.New("timeout"))配合On("Send", ...) - 务必检查 mock 是否被调用：调用
mockCtrl.Finish()或mock.AssertExpectations(t)，否则错误不会暴露
漏掉断言会导致 mock 失效但测试仍通过——这是最常踩的坑。
避免在测试中用 panic 替代 error 模拟
有些开发者会写 defer func() { recover() }(); panic("boom") 来模拟异常路径，这既破坏了 Go 的错误处理契约，又让测试难以区分真实 panic 和预期 panic。
正确做法是：
- 用
assert.Panics（testify）或assert.PanicsWithValue显式声明你期望 panic，且只用于真正该 panic 的场景（如空指针解引用、非法参数） - 绝大多数业务错误应走
error返回路径，而非 panic - 如果函数内部调用了可能 panic 的第三方库，应在包装层 recover 并转为 error，再在测试中模拟该 error
注意 error 类型比较与包装带来的测试陷阱
Go 1.13+ 引入了 errors.Is 和 errors.As，但测试中容易忽略 error 的包装层级：
- 若生产代码返回
fmt.Errorf("failed to write: %w", os.ErrPermission)，测试不能用err == os.ErrPermission，必须用errors.Is(err, os.ErrPermission) - 若 mock 返回的是
errors.New("db timeout")，而被测代码又用%w包装了一层，原始字符串就不可靠了——建议 mock 返回预定义变量（如var ErrDBTimeout = errors.New("db timeout")），再用errors.Is判断 - 使用
errors.Unwrap要谨慎：它只解一层，嵌套深时不如Is稳定
error 比较逻辑一旦写错，测试就变成“永远绿”或“永远红”，而且很难定位原因。
