如何在Golang测试中Mock当前时间_处理时序逻辑代码

应通过依赖注入 NowFunc 替代直接调用 time.Now()，避免全局变量或 init() 中固化时间；测试时传固定闭包，生产用 time.Now；慎用第三方 clock 包，优先函数参数注入。

用 time.Now 的依赖注入替代全局调用

直接调用 time.Now() 会让测试无法控制时间点，导致时序逻辑（比如超时判断、缓存过期）难以覆盖。必须把时间获取能力变成可替换的依赖。

常见错误是写个全局变量存 time.Now 函数再 mock —— 这在并发测试中会互相干扰，也不符合 go 的依赖管理习惯。

• 定义一个函数类型： type NowFunc func() time.Time
• 把原本直接调用 time.Now() 的地方，改成通过结构体字段或参数传入的 NowFunc 调用
• 生产代码里默认传 time.Now；测试时传一个固定返回值的闭包，比如 func() time.Time { return testTime }

避免在 init() 或包级变量里固化 time.Now

有些代码会在包初始化阶段就调用 time.Now() 计算默认值（比如配置里的默认过期时间），这会导致测试前时间就被“冻结”，后续所有测试都共享同一个初始时间点。

典型表现是：第一个测试跑完后，第二个测试发现缓存还没过期，明明已经过了 5 秒——其实它用的是第一个测试启动时的时间。

立即学习“go语言免费学习笔记（深入）”；

• 检查所有 var 声明和 init() 函数，删掉对 time.Now() 的直接调用
• 把这类计算推迟到首次使用时（懒加载），或作为构造函数参数传入
• 如果必须有默认值，用字符串（如 "30s"）或持续时间（30 * time.Second）代替绝对时间点

慎用 github.com/benbjohnson/clock 这类第三方 clock 包

它确实能统一替换 time.Now、time.Sleep、定时器等，但引入后容易掩盖设计问题：比如本该拆成小函数的时序逻辑，被包一层 clock 就糊弄过去了。

更实际的风险是：一旦某处漏了注入 clock（比如新写的工具函数忘了加参数），测试就又回到不可控状态，而且很难定位。

• 只在真正需要模拟整套时间系统（比如带 AfterFunc、Tick 的复杂调度逻辑）时才考虑引入
• 优先用函数参数或接口注入，而不是全局替换 time 包行为
• 如果用了，确保所有测试都显式创建并传递 clock.NewMock() 实例，不要复用

测试中验证时间偏移要小心 time.Sub() 的符号和精度

写断言时经常用 actual.Sub(expected) 判断是否“接近”，但容易忽略：如果 actual 比 expected 早，结果是负数，不等式恒成立。

另一个坑是 time.Time 默认带纳秒精度，而 time.Now() 在某些环境（比如 CI 容器）可能只有毫秒级更新，导致看似相等的两个时间点，== 判断失败。

• 用 actual.After(expected) || actual.Equal(expected) 替代 actual.Sub(expected) > 0
• 比较两个时间是否“基本相等”时，用 actual.Sub(expected)
• 或者直接用 assert.WithinDuration(t, expected, actual, 100*time.Millisecond)（testify）

真实项目里最常被忽略的，是那些藏在工具函数、中间件或日志打点里的隐式 time.Now() 调用——它们不在主业务路径上，但会让某个边缘 case 的测试始终 flaky。