Go中验证接口实现靠编译期赋值检查而非运行时语法，通过var _ Interface = impl{}触发；测试应聚焦接口行为，用接口参数设计函数并传入真实或mock实现，httptest.NewRecorder用于HTTP handler单元测试。
Go 里没有“检查某类型是否实现某接口”的运行时语法，测试接口的核心不是验证声明，而是验证行为是否符合契约——只要传得进去、跑得通、结果对，就说明实现正确。
用赋值语句触发编译期检查
这是最轻量也最关键的防线：Go 编译器会在你尝试把一个值赋给接口变量时，自动检查它是否实现了全部方法。一旦漏掉或签名不匹配，直接报错 missing method XXX。
- 在
_test.go文件里加一行不执行的赋值，比如var _ Reader = MyReader{}或var _ Reader = &MyReader{}——注意指针接收者和值接收者的区别 - 如果接口方法带指针接收者（如
func (r *MyReader) Read() string），那MyReader{}就无法赋值成功，必须用&MyReader{} - 这个检查只发生在编译期，不生成任何运行时开销，CI 里也能立刻捕获实现断裂
用接口参数写单元测试，别测结构体本身
真正的接口测试，是把你的业务函数设计成接收接口，然后在测试中传入真实实现或 mock，再断言输出或副作用。
- 错误做法：
mr := MyReader{}; got := mr.Read()—— 这是在测MyReader这个 struct，和接口无关 - 正确做法：定义
func Process(r Reader) string，再写Process(MyReader{})或Process(&MockReader{}) - 好处是能自然覆盖多种实现，比如内存版、HTTP 版、文件版
Reader，测试逻辑完全复用 - 如果接口方法返回 error，测试里一定要覆盖 error 路径，不能只看 happy path
手动 mock 接口比用工具更可控
对大多数项目，手写 mock 结构体比引入 gomock 或 mockgen 更快、更透明，也更容易理解调用链。
Golang Uber Dig
下载
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
立即学习“go语言免费学习笔记（深入）”；
- 定义一个 struct，字段是函数类型，比如
type MockUserRepo struct { GetUserFunc func(int) (*User, error) } - 实现接口方法时直接调用该字段：
func (m *MockUserRepo) GetUser(id int) (*User, error) { return m.GetUserFunc(id) } - 测试中可灵活控制返回值：
mock.GetUserFunc = func(id int) (*User, error) { return &User{ID: id}, nil } - 避免过度 mock：如果某个接口只有 1–2 个方法被用到，就别为整个“胖接口”写全量 mock，按需实现即可
httptest.NewRecorder 是 handler 单元测试的默认选择
测 HTTP 接口逻辑，优先用 httptest.NewRecorder，而不是启动真实服务——它不占端口、不走网络、响应可直接断言。
- 必须显式设置请求头，比如
req.Header.Set("Content-Type", "application/json")，否则很多 handler 会直接返回 415 -
recorder.Code默认是 0，不是 200；handler 没调w.WriteHeader就不会改它，务必检查 - 读响应体别用
rr.Body.String()做模糊匹配，优先json.Unmarshal(rr.Body.Bytes(), &expected)，避免字段顺序、空格、新增字段干扰 - 构造请求体要用
json.Marshal，别用fmt.Sprintf拼 JSON 字符串——引号转义和 null 处理很容易出错
最容易被忽略的是：接口测试不是为了证明“我写了实现”，而是为了守住“它被这样用时，必须这样响应”。所以每次加新方法、改签名、增 error case，都要同步更新对应的接口级测试，否则契约就形同虚设。
