应通过依赖注入 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。
