应抽象出Clock接口并显式注入，而非尝试mock time.Now()；Go 1.20+可用time.Clock，但需注意其作用域限制，推荐自定义接口统一管理时间依赖。
为什么 time.Now() 在测试里没法直接 mock
Go 标准库的 time.Now() 是个包级函数，不是接口方法，没法像 Java 那样靠依赖注入替换实现。硬写 time.Sleep(5 * time.Second) 等真实时间，测试就慢、不稳定、还可能被 CI 超时中断。
真正能控住时间的路只有一条：把时间获取逻辑抽象成接口，再传入可替换的实现。标准库其实早留了钩子——time.Clock 接口（Go 1.20+），但多数项目还在用自定义接口过渡。
- 别试图 monkey patch
time.Now（Go 不支持） - 别在业务代码里裸调
time.Now()，哪怕只调一次 - 如果用的是 Go < 1.20，自己定义
Clock接口即可，和标准库一致
怎么设计可测试的 Clock 接口并注入
最轻量的做法是定义一个函数类型或接口，让业务逻辑通过参数或字段接收它。推荐接口，更易 mock 和扩展：
type Clock interface {
Now() time.Time
Since(t time.Time) time.Duration
After(d time.Duration) <-chan time.Time
}注意：Since 和 After 不是必须的，但加了能覆盖更多场景（比如超时判断、倒计时逻辑）。如果你只用 Now()，那一个方法就够了。
立即学习“go语言免费学习笔记（深入）”；
使用 uber-go/dig 在 Golang 中实现依赖注入——基于反射容器，提供 Provide/Invoke、dig.In/dig.Out 参数与结果对象，支持命名依赖等
- 结构体字段注入比函数参数更常见，尤其对长期存活的服务对象（如 HTTP handler、worker）
- 避免全局变量存
Clock实例，否则并发测试会互相干扰 - 构造函数里设默认值：用
&RealClock{}或直接time.Now函数闭包
用 gomonkey 或 testify/mock 真的靠谱吗
不推荐。Go 官方明确不支持运行时函数替换，gomonkey 依赖 unsafe 和底层符号操作，在 Go 1.21+ 已出现兼容问题，CI 上容易静默失败；testify/mock 对函数无能为力，只能 mock 接口——而你得先有接口。
真正稳定的方式是「提前抽象 + 构造时注入」，mock 成本极低：
type MockClock struct {
now time.Time
}
func (m *MockClock) Now() time.Time { return m.now }
func (m *MockClock) Set(t time.Time) { m.now = t }- 测试中 new 一个
*MockClock，手动推进时间：clock.Set(clock.Now().Add(30 * time.Minute)) - 不要 mock 接口以外的东西，包括
time.Ticker、time.Timer—— 它们都该由Clock接口统一提供 - 如果用了第三方库（如
github.com/robfig/cron），查它是否支持传入Clock；不支持就封装一层适配器
Go 1.20+ 的 time.Clock 怎么用才不踩坑
标准库新增的 time.Clock 接口和 time.Now() 等函数都接受一个可选的 time.Clock 参数，但注意：它只影响当前 goroutine，且仅对新创建的 timer/ticker 生效，不会改变已存在的 time.After 或 time.Tick 行为。
所以别指望靠 time.RunWithClock 全局切时间——它只适合极简单测，比如一行 time.Now().Clock(...)。
- 生产代码中仍应坚持「显式注入
Clock接口」，而不是依赖time.RunWithClock -
time.NewTicker和time.AfterFunc没有Clock版本，必须自己封装（例如clock.AfterFunc(d, f)） - 标准库的
time.Clock接口目前只有Now()方法，After/Tick还没加进去，别等
时间相关的逻辑越靠近边界（如 handler 入口、job 启动点），越早做抽象，后面补 mock 就越痛苦。真等到发现三个地方都裸调了 time.Now() 再改，不如重写。
