go中time.now()不能直接mock，因其是包级函数而非接口方法；正确做法是定义clock接口并注入realclock或testclock实现，避免硬编码调用，确保每次获取时间都通过接口调用。
Go 测试中 time.Now() 为什么不能直接 mock
因为 time.Now 是一个包级函数，不是接口方法，Go 不支持直接替换包函数（除非用 monkey 这类危险 patch 工具，不推荐）。硬写 time.Sleep 等真实等待，测试慢、不稳定、不可控。
正确做法是把时间依赖抽象成接口，让业务逻辑接收可替换的时钟实现：
- 定义
Clock接口，含Now()方法 - 生产代码用
time.Now实现该接口（如RealClock{}） - 测试时传入
FakeClock或TestClock，手动控制返回时间 - 避免在 struct 字段里硬编码
time.Now调用，改用注入的clock.Now()
用 testify/mock 或 interface + struct 实现 Clock Mock
不需要第三方 mock 框架也能干净解耦。最轻量的方式是自己定义接口和两个实现：
// 定义接口
type Clock interface {
Now() time.Time
}
<p>// 生产实现
type RealClock struct{}
func (RealClock) Now() time.Time { return time.Now() }</p><p>// 测试实现
type TestClock struct {
t time.Time
}
func (tc <em>TestClock) Now() time.Time { return tc.t }
func (tc </em>TestClock) Set(t time.Time) { tc.t = t }
使用时，把 Clock 作为参数或字段注入到被测对象中。常见错误是只在初始化时调一次 time.Now() 存为字段值，导致后续测试无法推进时间 —— 必须每次调用都走 clock.Now()。
立即学习“go语言免费学习笔记（深入）”；
time.Now() 直接替换的“伪 mock”陷阱（time.AfterFunc / time.Sleep）
很多同学试图用 time.Sleep(1 * time.Second) 配合 time.Now() 测时间差，结果在 CI 上因调度延迟失败；或用 time.AfterFunc 做异步断言，但没处理 goroutine 泄漏。
-
time.Sleep不精确，且让测试变慢，单测应毫秒级完成 -
time.AfterFunc启动的 goroutine 若没等完就结束测试，会 panic 或漏断言 - 真实时间相关逻辑（如超时、重试）建议用
context.WithTimeout+ 可控时钟组合，而非依赖系统时钟跳变 - 若必须验证“过了一秒后触发”，用
TestClock手动Set两个不同时间点再断言，而不是等
第三方库选型：clockwork vs gomock vs 自己写
社区有 github.com/jonboulle/clockwork，提供 clockwork.NewFakeClockAt() 和 .Advance()，语义清晰，适合复杂时间推进场景；但引入额外依赖，且其 FakeClock 不兼容自定义 Clock 接口。
- 小项目、简单推进：自己写
TestClock最轻、最可控 - 需模拟周期性 tick、定时器队列、多 goroutine 时间同步：用
clockwork - 别用
gomockmocktime包 —— 它没法 mock 函数，只能 mock 接口，而time.Now不是接口 - 注意
clockwork.FakeClock的Now()返回的是内部快进后的时间，但AfterFunc注册的回调仍需显式调用BlockUntil或Tick触发
真正容易被忽略的，是时间精度单位和时区。比如用 time.Date(2024, 1, 1, 0, 0, 0, 0, time.UTC) 构造测试时间，但业务代码用了 time.Local，结果比较失败 —— 测试时务必统一时区，别依赖默认值。
