go test 中断言 mock 方法调用次数最可靠方式是 gomock 的 times(n)，需提前声明；未声明则默认只允许 1 次，超次 panic；手动统计需导出计数器字段并注意并发安全与重置时机。
Go test 中如何断言某个 Mock 方法被调用了几次
直接用 gomock 的 Times() 是最常用也最可靠的方式，但必须配合 AnyTimes() 或具体期望次数提前声明，否则默认只允许调用 1 次，多一次就 panic。
常见错误现象：Unexpected call to *mockxxx.MethodName —— 其实不是没 mock 成功，而是你没告诉 mock 期望调多少次，它按“恰好 1 次”守着，结果你调了 2 次就炸了。
- 使用场景：验证重试逻辑、缓存穿透时的多次 fallback 调用、事件驱动中重复触发的 handler
-
Times(0)表示“绝对不能调”，Times(3)表示“必须且只能调 3 次”，Times(1).AnyTimes()不合法，AnyTimes()本身已隐含“不限次数” - 注意兼容性：
gomock v1.6+支持MinTimes(n)和MaxTimes(n)，老版本只能靠Times(n)或手写计数器
示例：
mockObj.EXPECT().FetchData().Times(2)—— 这行之后，测试里必须让
FetchData() 被调 2 次，少或多都会失败。
不用 gomock 时怎么手动统计方法调用次数
当用的是自定义 interface + struct 实现（比如轻量 mock），就得自己加计数器字段，然后在方法里递增。关键点是：计数器得是导出字段或带导出 getter，否则测试包读不到。
立即学习“go语言免费学习笔记（深入）”；
容易踩的坑：在测试 setup 阶段忘了重置计数器，导致上一个测试的调用次数污染当前测试；或者把计数器放在闭包里，多个 goroutine 并发调用时没加锁，结果计数值错乱。
- 使用场景：单元测试中快速 mock 一个简单依赖，不想引入
gomock生成代码 - 参数差异：如果方法有参数，而你只关心调用频次不关心参数值，计数器放 struct 里就行；如果还要校验某次调用的参数，就得用 slice 记录每次入参
- 性能影响几乎为零，但要注意并发安全 —— 单测默认串行，但如果用了
t.Parallel()，就得给计数器加sync.Mutex或用atomic.Int32
示例：
type MockDB struct { CallCount int }<br>func (m *MockDB) Query() { m.CallCount++ }，测试里检查 mockDB.CallCount == 2 即可。
为什么 t.Cleanup 里清零计数器反而会失效
因为 t.Cleanup() 是在测试函数 return 之后执行，而调用次数校验通常写在测试末尾（比如 if mock.CallCount != 2 { t.Fatal(...) }），此时 Cleanup 还没跑，清零动作根本没发生 —— 所以不是“清零了但没用”，是“根本没来得及清零”。
真正该清零的地方，是每个测试用例开头，或者用子测试（t.Run）把初始化和校验包在一起。
- 常见错误现象：第二个子测试发现
CallCount是 4 而不是预期的 2，误以为是前一个测试没清理 - 正确做法：在
t.Run内部 new 一个新的 mock 实例，或显式赋值mock.CallCount = 0 - 不要依赖
Cleanup做状态重置，它适合关文件、停 server 这类“收尾”，不适合“前置准备”
Log 输出里看到方法被调了，但 Times(n) 还是失败
大概率是 mock 对象没真正被注入到被测代码里，log 是真实实现打的，不是 mock 打的 —— 你校验的是 mock 的调用次数，但实际走的是原实现。
典型表现：日志里有 “calling FetchData”，但 mockObj.EXPECT().FetchData().Times(1) 报错说 “0 calls instead of 1”。说明 mock 没生效。
- 检查依赖注入方式：是传参进去？还是通过全局变量/单例？mock 对象必须出现在被测代码实际调用的路径上
- 确认 interface 实现是否一致：比如 mock 实现的是
Fetcher接口，但被测代码里用的是*realFetcher类型断言，那 mock 根本不会被调到 - goland 调试技巧：在 mock 方法里加
panic("hit mock")，看会不会真 panic，能最快验证 mock 是否接入成功
这事一旦出错，所有调用次数校验都失去意义 —— 校验对象错了，数字再准也没用。
