前一个用例把时钟冻在 2026-03-01,用完没解冻,后面的下单用例算出的超时时间是负数。断言报 expected true but was false。乍看像缓存或者权限的锅,追下去往往不是。
@BeforeEach
void freeze() { clock = Clock.fixed(Instant.parse("2026-03-01T00:00:00Z"), ZoneOffset.UTC); }
@AfterEach
void reset() { clock = Clock.systemUTC(); }
追下去是这么回事:冻结时钟改的是进程级共享状态,同一个 JVM 里所有类串着跑。没有 afterEach 还原,后面的用例都活在那个时间点。
「时间冻结未恢复」相关的日志我一般连着看前后五分钟,单看一条报错经常判断不出是哪一步失败。接口问题先分清是没发出去、发出去了没收到,还是收到了处理失败。
偶发问题先统计频率,一小时几次和一天一次,查法完全不同。改完顺手把文档补一句,省得下次自己重新推一遍。
监控和日志的时间要对上,时区不一致会多绕很大一圈。
具体做法是,把冻结和解冻写成成对的生命周期方法;用 try/finally 或现成的时钟规则 避免漏写;单类调试也走同一套 不手工设时间;跑全量确认再无用例读到 2026-03-01。
验收就看一点,单独跑和全量跑结果一致 日志里不再出现 2026-03-01 这个固定日期。
