new Date() 在单元测试中不可控，因系统时钟差异导致断言失败；应抽离时间依赖为可注入的 useClock Hook，配合 fake timers 和时区隔离实现稳定测试。
为什么 new Date() 在单元测试里总不按预期走
因为真实时间不可控，每次跑测试都可能因系统时钟差异导致断言失败。比如测试“今天生成的订单号是否含当前日期”，new Date() 返回的是运行时刻，不是你写用例时想模拟的那个“今天”。
更麻烦的是，某些逻辑依赖时间差（如过期判断）、定时器（setTimeout）、或全局时间戳（Date.now()），直接 new 一个实例根本没法稳定复现。
- 不要 patch 全局
Date构造函数——它影响整个测试环境，容易污染其他用例 - 避免在组件内部直接调用
new Date()或Date.now()——耦合太紧，无法注入控制点 - 优先把时间获取逻辑抽成可替换的依赖，而不是硬编码在 render 或生命周期里
React 中用 Clock 组件封装时间依赖的实操方式
所谓 Clock，不是 UI 组件，而是一个提供时间值的 React Hook 或 Context Provider。它把“当前时间”变成可注入、可 mock 的 prop 或 context 值。
典型做法是定义一个 useClock() Hook，内部默认读取 Date.now()，但允许传入 now 参数覆盖：
function useClock({ now } = {}) {
const [time, setTime] = useState(now ?? Date.now());
useEffect(() => {
if (now !== undefined) return;
const timer = setInterval(() => setTime(Date.now()), 1000);
return () => clearInterval(timer);
}, [now]);
return time;
}
这样在测试中就能固定时间：
render(<MyComponent time={1717027200000} />); // 2024-05-30 00:00:00
- 生产环境不传
now，自动刷新；测试时传死值，完全可控 - 如果组件需要格式化时间（如
toLocaleDateString()），也建议把Intl.DateTimeFormat实例或格式化函数作为 prop 注入，避免依赖本地时区 - 注意：
useEffect中的定时器只在now未定义时启用，否则会跳过——这是关键隔离点
Mock setTimeout 和 setInterval 时别只 stub 不 advance
很多测试库（如 Jest）提供 jest.useFakeTimers()，但它只是冻结时间，并不自动推进。如果你写了 setTimeout(() => doX(), 5000)，不手动调用 jest.advanceTimersByTime(5000)，回调永远不会触发。
- 用
jest.useFakeTimers('modern')替代旧版，支持advanceTo和更精确的微任务调度 - 对依赖轮询的组件（如倒计时、心跳检测），必须显式
advanceTimersByTime()或runAllTimers()，否则测试会超时或跳过逻辑 - 测试完记得
jest.useRealTimers()——尤其在 afterEach 里，否则下一个测试可能还在 fake 模式下，行为诡异
时区和夏令时是 Clock Mock 最容易漏掉的坑
本地开发机可能是 CST，CI 环境默认 UTC，而用户浏览器又各自有本地时区。单纯 mock 时间戳（毫秒数）能绕过时区问题，但一旦涉及 toLocaleTimeString()、getHours() 这类方法，结果就不可控了。
解决方案不是禁止使用这些 API，而是统一约定时间上下文：
- 所有业务时间逻辑基于 UTC 处理（如有效期判断、日志时间戳）
- UI 层才做时区转换，且通过明确的
timeZoneprop 控制，例如：<Clock timeZone="Asia/Shanghai" /> - 测试时用
Intl.DateTimeFormat的resolvedOptions().timeZone断言是否生效，比直接 expect 字符串更可靠
真正难的不是怎么 mock，而是决定哪一层该信任时间、哪一层该隔离时间——Clock 的价值不在组件本身，而在帮你划清这条线。
