MockClock 不能直接替换系统时间，因为 System.currentTimeMillis() 是 JVM 底层 native 调用，无法被 Mockito 等普通框架拦截；可行方案是将时间获取逻辑抽离为可注入的 Clock 依赖，并在测试中使用 Clock.fixed 或 Clock.offset 替代。
MockClock 为什么不能直接替换系统时间
因为 System.currentTimeMillis() 是 JVM 底层调用操作系统时钟，无法被普通 Mock 框架（如 Mockito）拦截——它不是对象方法，而是静态 native 调用。强行 mock 静态方法（比如 PowerMock）不仅破坏测试隔离性，还容易在 JDK 9+ 因模块限制失败。
真正可行的路径是：把时间获取逻辑抽离成可注入的依赖，再用 MockClock 或 ManualClock 替代。Spring Boot 2.6+ 默认支持 Clock 注入，但老项目往往直接写死 new Date() 或 Instant.now()，这时必须先改代码。
- 所有时间相关操作（如
Instant.now()、LocalDateTime.now()）必须显式传入Clock实例，例如Instant.now(clock) - Spring 环境下推荐声明
@Bean @Primary Clock clock() { return Clock.systemUTC(); }，测试时用@TestConfiguration替换为Clock.fixed(...)或MockClock - 注意
java.time.Clock是不可变的，每次“推进时间”都得新建实例，别试图 mutate 原有Clock
MockClock vs ManualClock：选哪个做限时抢购测试
MockClock 不是 JDK 标准类，常见于测试库（如 io.github.resilience4j:resilience4j-test）或自定义实现；而 ManualClock 是 org.mockito.internal.util.MockUtil 提供的（已弃用），实际更常用的是 Clock.fixed(Instant, ZoneId) 或 Clock.offset(Clock, Duration)。
限时抢购核心要验证的是「时间窗口内允许下单，超时立即拒绝」，重点不在模拟“流逝”，而在精确控制“当前时刻”。所以：
- 用
Clock.fixed(Instant.parse("2024-01-01T10:00:00Z"))测试边界点（如开抢瞬间、截止前 1ms、过期后 1ms）最可靠 - 需要连续推进时间（比如模拟用户从进页面到下单耗时 800ms）时，用
Clock.offset(baseClock, Duration.ofMillis(800))更轻量，不用反复 new - 避免用第三方
MockClock类，除非它明确支持线程安全的setInstant()—— 多线程并发抢购测试中，时间跳变必须全局可见且原子
测试中 Clock 注入失败的典型现象
常见错误不是编译报错，而是测试通过但逻辑没跑对：比如抢购接口始终返回“活动未开始”，或超时后仍能下单。根本原因是 Clock 没生效，实际走的还是系统时钟。
排查顺序：
- 检查被测类是否真的接收了
Clock参数（构造器注入 / setter 注入 / 方法参数），而不是在内部硬编码Instant.now() - 确认测试上下文里
@Autowired Clock clock拿到的是你配置的 mock 实例，不是默认的Clock.systemDefaultZone()（加断点或System.out.println(clock.toString())验证） - Spring Boot WebMvcTest 场景下，
@MockBean Clock可能不生效，因为 Controller 层依赖的 Service 用的是另一个 Bean Scope 的 Clock，优先用@Import(TestClockConfig.class)显式覆盖 - 注意 LocalDateTime.now() 和 Instant.now() 默认都依赖系统时钟，必须显式传参，例如
LocalDateTime.now(clock)
并发抢购测试里时间推进的陷阱
单线程测试推进时间很简单，但真实抢购是多线程争抢库存。如果每个线程用各自的 Clock 实例，就失去了“全局一致当前时间”的意义——A 线程看到 10:00:00.000，B 线程看到 10:00:00.001，会导致预期外的并发行为。
正确做法是共享同一个 Clock 实例，并确保所有线程调用都基于它：
- 用
Clock.fixed(...)时，所有线程自然共享同一时刻，适合测试“瞬时状态” - 用
Clock.offset(...)模拟耗时时，必须保证 offset 是相对于同一个 base clock，且 base clock 是 fixed 或 system（不能是 ticking） - 绝对不要在 Runnable/Callable 里 new Clock，尤其避免
Clock.systemUTC()—— 它会立刻切回真实时间 - 如果业务代码里用了
ScheduledExecutorService做倒计时推送，记得用new ScheduledThreadPoolExecutor(1, r -> {...})并手动控制其触发时机，否则它不认你的 Clock
限时逻辑的脆弱点从来不在算法本身，而在时间源是否真正可控。哪怕只有一处 new Date() 漏网，整个时间旅行就脱轨了。
