go测试中mock不稳定依赖的核心前提是重构代码使依赖可替换，即所有外部依赖必须通过构造函数参数传入且类型为接口，禁止包级变量和硬编码i/o调用，并为第三方sdk定义最小接口及适配器。
Go测试中Mock不稳定依赖的核心前提
不能直接Mock第三方结构体或包级变量，必须先重构代码使其可被替换。Go里没有“自动注入”机制，NewOrderService这类构造函数不接收依赖，就等于放弃了Mock能力——哪怕用gomock生成再多接口实现，运行时也根本进不去。
- 检查业务结构体是否所有外部依赖都通过构造函数参数传入，类型是接口而非具体类型（如
*sql.DB、*s3.Client） - 确认没有包级变量初始化资源，比如
var client = http.DefaultClient或db, _ = sql.Open(...) - HTTP、数据库、文件IO等I/O操作是否全部抽象为参数或字段，而不是在方法内部硬编码调用
Mock AWS S3 或其他 SDK 时常见报错及修复
典型错误：cannot use *mockS3Client as *s3.Client。这不是工具问题，是类型系统在拒绝你绕过接口契约。
- 禁止直接把第三方SDK的客户端类型（如
s3.Client）当作函数参数或结构体字段 - 在你的业务模块（如
order/internal/dep）定义最小接口，只包含实际用到的方法：GetObject(ctx, params)、PutObject(ctx, params) - 写一个适配器包装真实
s3.Client，让它实现你定义的接口；测试时用struct{}或手写MockS3实现同一接口即可 - 避免在测试文件里
import github.com/aws/aws-sdk-go-v2/service/s3——这会让测试间接依赖生产SDK，破坏隔离
手写轻量Mock比自动生成更稳的场景
当接口只有1–2个方法（比如UserRepo.GetByID(id int) (*User, error)），用mockery或gomock反而引入冗余代码和维护负担。
- 直接定义
type MockUserRepo struct { users map[int]*User }，实现对应方法，5行内搞定 - 支持表驱动测试：不同测试用例传入不同
users数据，无需改Mock逻辑 - 避免框架生成的
EXPECT()链式调用——它强制要求调用顺序和次数，在复杂流程中极易因重构失败 - 对返回值做细粒度控制：比如让第2次
GetByID返回nil, errors.New("timeout")，模拟网络抖动
HTTP 和数据库依赖的Mock替代方案
不要试图Mockhttp.Get或database/sql的全局行为，而应把客户端作为显式依赖传入。
- 函数签名从
func ProcessOrder(id string) error改为func ProcessOrder(id string, client HTTPDoer) error，其中HTTPDoer是自定义接口：Do(req *http.Request) (*http.Response, error) - 测试时传入
&http.Client{Transport: &testRoundTripper{}}，或直接用httptest.NewServer启动本地mock服务 - 数据库操作统一走
sqlmock：它拦截*sql.DB的Query/Exec调用，但前提是你的业务代码接收的是*sql.DB参数，而不是自己sql.Open - 注意
sqlmock不支持db.QueryRowContext以外的上下文变体，若用db.QueryRow会panic，得补全context参数
最常被忽略的一点：Mock不是为了“看起来像测试”，而是为了让每次执行都可控。如果你的Mock需要读配置、查环境变量、或者依赖另一个未Mock的模块，那它已经失去意义了。
golang免费学习笔记（深入）：立即使用
在学习笔记中，你将探索golang的核心概念和高级技巧！
