Go语言无法直接mock普通函数，因其缺乏运行时函数指针替换机制；必须通过抽接口+依赖注入重构代码，或手写fake，而非强行patch。
Go 语言里不能直接 mock 普通函数——这不是工具链限制，而是语言设计使然。你得重构代码，把函数调用变成接口方法调用，再注入 mock 实现。硬要 patch http.Get 或 time.Now，要么失败，要么埋下 CI 随机超时、panic 的坑。
为什么不能直接 mock 包级函数？
Go 没有运行时函数指针替换机制（不像 Python 的 patch 或 JS 的 jest.mock）。gomock、testify/mock 等工具只处理接口，不碰函数。试图 mock os.ReadFile 或 rand.Intn 会编译失败或静默失效。
- gomock 生成的代码全是基于接口的，
mockgen -source=xxx.go只认type X interface{...} - 第三方库如
cloud.google.com/go/storage.Client提供了接口（如storage.BucketHandle），但net/http.DefaultClient是结构体，没法直接 mock - 强行用
httpmock拦截http.DefaultClient，对自定义http.Transport无效，且不报错——测试看似通过，实际没走 mock
怎么改代码才能 mock？
核心就两步：抽接口 + 依赖注入。不是加个 wrapper 就行，要让被测逻辑真正接收可替换的依赖实例。
- 把外部调用封装进接口方法，比如把
db.QueryRow(...)改成repo.GetUser(id)，其中repo是接口字段 - 避免在函数体内 new 实例，比如不要写
client := &HTTPClient{}；改成从参数或结构体字段读取：func (s *Service) Do(ctx context.Context) error { return s.client.Do(ctx) } - HTTP 客户端必须可配置 URL 和
*http.Client，否则测试只能靠httptest.Server启服务，但若代码里硬编码http.DefaultClient，你就只能重写逻辑
手写 fake 还是用 gomock？
绝大多数情况，手写 fake 更快、更稳、更容易断言。gomock 只在两类场景值得用：mock 外部 module 的接口（比如 AWS SDK），或你的接口方法超过 10 个且调用顺序/参数匹配必须严格校验。
- 手写 fake 示例：
type MockUserRepo struct { SaveFunc func(*User) error }，测试里直接赋值mock.SaveFunc = func(u *User) error { return nil } - gomock 生成后必须调用
ctrl.Finish()，否则期望未验证就通过；改了接口签名后不重跑mockgen，会导致编译失败或 panic - fake 字段可导出（如
Called bool、LastID int），测试中直接assert.True(t, mock.Called)，不用学EXPECT().Times(2)那套
HTTP 依赖最容易踩的坑
HTTP 测试失败，90% 是因为没把请求入口做成可配置。别信“先跑通再说”，一到 CI 就暴露。
- 错误写法：
resp, err := http.Get("https://api.example.com/users/1")—— 无法 mock，强依赖网络 - 正确写法：定义
type HTTPDoer interface { Do(*http.Request) (*http.Response, error) }，测试时传入&http.Client{Transport: &mockRoundTripper{}} - 更推荐用
httptest.Server：启动真实 handler，传server.URL给 client；注意路径拼接别写死，handler 返回要用json.NewEncoder(w).Encode()，否则Content-Type缺失导致解析失败
最常被忽略的一点：mock 不是目的，控制边界才是。哪怕只 mock 一个方法，也要确保它真被调用——检查日志、打断点、或者在 fake 里加 panic("unexpected call")。否则你以为隔离了依赖，其实还是在打真实服务。
