应通过定义 clock 接口抽象时间控制，如 type clock interface { tick(d time.duration)
如何在测试中 mock time.Ticker 和 time.Timer
Go 标准库的定时任务逻辑（如 time.Tick、time.NewTicker）依赖真实时间，直接跑单元测试会变慢甚至不稳定。核心思路是把时间控制权交给测试——用可控制的接口替代硬编码的 time.Ticker。
推荐做法：定义一个时钟抽象，例如：
type Clock interface {
Tick(d time.Duration) <-chan time.Time
After(d time.Duration) <-chan time.Time
}
生产代码中用 time.Now() 或 time.NewTicker()；测试中注入一个模拟实现，比如 testClock，它允许你手动触发“时间流逝”：
- 用
chan time.Time手动发送时间点，模拟 ticker 触发 - 避免 sleep 等待，所有“等待”都变成通道接收 + 主动发送
- 注意：不要在测试里写
time.Sleep(100 * time.Millisecond)，这是反模式
使用 github.com/benbjohnson/clock 替代手写 mock
这个第三方库提供了线程安全、可快进、可暂停的时钟实现，比自己写更可靠。它导出的 clock.NewMock() 返回一个 clock.Clock 接口，和标准 time 包高度兼容。
立即学习“go语言免费学习笔记（深入）”；
典型用法：
c := clock.NewMock() ticker := c.Ticker(5 * time.Second) // …… 启动你的任务逻辑，传入 ticker.C <p>// 模拟过去 6 秒 c.Add(6 * time.Second) // 此时 ticker.C 应该已收到至少一次 tick
- 所有基于
c.After()、c.Ticker()、c.Now()的逻辑都会响应c.Add() - 不需要 goroutine 控制或 channel select 判断超时，
Add()是同步的 - 注意：如果被测代码内部调用了
time.Now()（没通过参数传入 clock），mock 就失效了 —— 必须把时钟作为依赖显式传入
测试含 context.WithTimeout 的定时任务逻辑
很多定时任务会配合 context.WithTimeout 做兜底控制，但测试时不能真等 timeout 触发。关键在于：把 context 构建也抽离出来，或者直接传入已取消的 context。
- 错误写法：
ctx, cancel := context.WithTimeout(context.Background(), 3*time.Second)写死在函数内 → 测试只能等 3 秒 - 正确做法：让函数接受
ctx context.Context参数，或提供一个WithContext(ctx)选项方法 - 测试中可传入
context.WithCancel后立即cancel()，验证提前退出路径 - 也可用
clock.WithDeadline（需搭配github.com/benbjohnson/clock）来精确控制 deadline 到达时机
为什么 time.AfterFunc 在测试中难处理
time.AfterFunc 是黑盒异步调用，无法拦截、无法等待、无法断言是否执行。一旦出现在被测函数中，就极大增加测试难度。
- 最稳妥解法：把它包装成可替换的函数类型，例如
func(d time.Duration, f func()) *time.Timer，测试时替换为立即执行或记录调用的 stub - 避免在核心逻辑里直接调用
time.AfterFunc，尤其不要让它承担关键状态变更 - 如果必须用，至少确保它只做副作用小的操作（如打日志），主业务逻辑仍由可控的 ticker 或 channel 驱动
真正麻烦的不是“怎么让时间变快”，而是“哪些地方悄悄绑死了 time 包”。每多一个隐式依赖，测试的可控性就降一分。
