不能直接用 time.sleep 模拟时间流逝，因为它拖慢测试、不可控、易干扰并发测试，且依赖外部时钟导致 ci 环境下断言不稳定；真正需模拟的是“被测代码感知到时间推进”，应通过闭包封装可替换的 time.now 和定时器函数来实现精准可控的时间仿真。
为什么不能直接用 time.Sleep 模拟时间流逝？
因为真实等待会拖慢测试、不可控、且并发下容易干扰其他测试。更糟的是，它让测试变成“依赖外部时钟”的脆弱行为——CI 环境时钟抖动、容器内 CLOCK_MONOTONIC 行为差异，都可能让 time.Sleep(1 * time.Second) 实际休眠 980ms 或 1050ms，导致断言失败。
真正要模拟的不是“睡一秒”，而是“让被测代码感知到时间已推进指定量”。闭包在这里的作用是把时间推进逻辑从全局时钟解耦出来，交由测试控制。
用闭包封装可替换的 time.Now 和 time.AfterFunc
核心思路：把时间相关函数抽成变量（或参数），测试时用闭包构造的“假时间”覆盖它们。例如：
// 生产代码中
var nowFunc = time.Now
var afterFunc = time.AfterFunc
<p>func waitForEvent(timeout time.Duration) error {
done := make(chan struct{})
timer := afterFunc(timeout, func() { close(done) })
defer timer.Stop()
select {
case </p><p>测试时用闭包构造可控时间源：</p><pre class="brush:php;toolbar:false;">// 测试中
clock := &fakeClock{now: time.Unix(0, 0)}
nowFunc = func() time.Time { return clock.now }
afterFunc = func(d time.Duration, f func()) *time.Timer {
// 立即触发，或按 fakeClock 的规则延迟
go func() { time.Sleep(time.Nanosecond) /* 触发时机由 clock 控制 */; f() }()
return &time.Timer{} // 返回空 timer，避免 Stop 报错
}
- 闭包捕获
clock实例，使每次调用都能读取/推进其内部状态 - 不要试图 patch
time.Now全局函数——Go 不支持 monkey patch，且会污染其他测试 - 如果被测逻辑用了
time.After或time.Tick，同样需替换为闭包封装的版本
闭包里维护单调递增的虚拟时间戳
很多场景需要“推进时间 5 秒”，而不是“立即触发回调”。这时闭包要管理一个可进化的时钟：
type fakeClock struct {
mu sync.Mutex
now time.Time
step time.Duration
}
<p>func (c *fakeClock) Now() time.Time {
c.mu.Lock()
defer c.mu.Unlock()
t := c.now
c.now = c.now.Add(c.step)
return t
}</p><p>func (c *fakeClock) Advance(d time.Duration) {
c.mu.Lock()
defer c.mu.Unlock()
c.now = c.now.Add(d)
}</p>
测试中这样用：
clock := &fakeClock{now: time.Unix(0, 0), step: time.Second}
nowFunc = clock.Now
// ... 运行被测逻辑
clock.Advance(5 * time.Second) // 模拟过去 5 秒
// 此时再调用 nowFunc() 就返回 Unix(5, 0)
-
Advance必须是显式调用，否则闭包里的now不会自动跳变 - 如果被测逻辑依赖
time.Since，记得也提供对应的Since方法，基于clock.now计算 - 并发调用
Advance和Now时，sync.Mutex不可省略——即使测试单线程，代码本身可能并发访问
容易漏掉的定时器清理和 panic 场景
闭包模拟时间时，常忽略两个现实问题：
-
time.AfterFunc返回的*time.Timer被Stop()后，其回调不会执行——但你的 fake 实现若没模拟这个语义，就会误触发 - 如果被测逻辑在定时器触发前 panic，而你没在 defer 中清理 fake timer 的 goroutine，会导致测试 goroutine 泄漏
- 某些库（如
golang.org/x/time/rate）内部用time.NewTimer，需一并替换；只换AfterFunc不够
最稳妥的做法：所有 fake 时间函数都返回可 Stop() 的伪 Timer，并在测试结束时统一调用 timer.Stop() ——哪怕它什么也不做，只是满足接口契约。
闭包本身不解决资源泄漏，它只是把控制权交给你；真正的难点在于，要模拟出和原生 timer 一致的生命周期语义，而不是仅仅“看起来快”。
