Go测试中不能直接用time.Now()，因其返回真实系统时间导致结果不可靠、边界难控、并发易失败；应通过Clock接口抽象时间依赖，注入mockClock等可控实现，并统一替换定时器相关调用。
Go 测试中为什么不能直接用 time.Now()
因为 time.Now() 返回真实系统时间，导致测试不可靠：结果随运行时刻变化、无法控制边界条件（比如刚好跨秒/跨天）、并发测试可能因微小时间差失败。硬 sleep 等待更是低效且不稳定。
用接口抽象时间依赖，注入可模拟的 time.Time 源
核心思路是把时间获取逻辑从硬编码改为依赖接口，测试时传入可控实现。最常用的是定义一个 Clock 接口：
type Clock interface {
Now() time.Time
}
// 生产代码中使用
func ProcessWithDeadline(clock Clock, timeout time.Duration) error {
start := clock.Now()
// ... 业务逻辑
if clock.Now().After(start.Add(timeout)) {
return errors.New("timeout")
}
return nil
}
测试时用 mockClock 控制返回值：
type mockClock struct {
t time.Time
}
func (m mockClock) Now() time.Time { return m.t }
func TestProcessWithDeadline(t *testing.T) {
clk := mockClock{t: time.Date(2025, 1, 1, 12, 0, 0, 0, time.UTC)}
err := ProcessWithDeadline(clk, time.Second)
// 此时所有 Now() 都返回固定时间，可精确断言
}
- 避免全局变量或包级函数直接调用
time.Now()，否则难以替换 - 若已有大量直调
time.Now()的旧代码，可先封装一层clock.Now()并逐步迁移 - 注意结构体字段是否导出 ——
mockClock的t字段应导出，否则测试中无法设置
使用 github.com/benbjohnson/clock 库简化模拟
该库提供开箱即用的 clock.Clock 接口和多种实现（RealClock、MockClock、SettableClock），比手写更健壮。
import "github.com/benbjohnson/clock"func DoWork(c clock.Clock) { t := c.Now() // ... }
func TestDoWork(t testing.T) { clk := clock.NewMock() clk.Add(5 time.Second) // 手动推进时间
DoWork(clk) if !clk.Now().Equal(time.Now().Add(5 * time.Second)) { t.Fatal("time not advanced correctly") }
}
-
MockClock默认从 Unix 零点开始，每次Add()推进内部时间，适合模拟耗时操作 -
SettableClock允许直接Set()到任意时间点，适合测试边界（如闰秒、时区切换） - 注意它不拦截系统调用 —— 如果代码里混用了
time.Sleep()，仍需配合clk.Sleep()替代
测试定时器、Ticker 和超时逻辑的常见陷阱
直接用 time.AfterFunc 或 time.NewTimer 会触发真实系统调度，导致测试慢或随机失败。必须统一走模拟时钟的对应方法。
- 把
time.AfterFunc(d, f)改为clk.AfterFunc(d, f) - 把
time.NewTimer(d)改为clk.Timer(d) - 把
time.Tick(d)改为clk.Ticker(d) - HTTP 客户端超时等底层依赖
time.Timer的场景，需传入自定义http.Client并设置Transport的IdleConnTimeout等字段为模拟值
最容易被忽略的是：哪怕只有一处漏掉替换，整个测试就可能退化为真实时间驱动 —— 尤其在第三方库内部调用 time.Now() 或 time.Sleep() 时，需检查其是否支持传入 clock.Clock。
