把它做成生产功能之前，需要先拆开协议事实、产品承诺和运行成本，三者混在一起很容易得到错误结论。 真实 sleep 使测试慢且不确定，也无法控制同一毫秒事件顺序。虚拟时钟保留单调时间和任务优先级，推进时执行所有到期回调直到稳定。
测试要把状态机、故障注入和真实浏览器组合起来。确定性用例守住已知契约，随机时序寻找竞态，失败 seed 和两端轨迹必须保存成永久回归。
落地方案的关键部件
实现之前先列出不可违反的不变量，再为性能与体验留出调节参数。参数可以灰度，身份、权限和终态规则不能在运行时随意漂移。
- 业务代码只依赖 Clock 接口的 now、setTimeout 与 clear；测试按下一事件跳跃，并对零延迟递归设置迭代上限防死循环。
- 把协议事实、用户意图和自动恢复分层；自动化只能恢复事实，不能推翻用户明确选择。
- 重试必须带幂等键、退避和截止时间；超过截止时间后建立新任务，而不是继续复活旧回调。
“虚拟时钟测试超时与退避：不 sleep，也能跑完整一天”的交付标准是正常路径可用、异常路径收敛、资源有界，并且用户能理解系统为何采用当前状态。 这样得到的不是演示代码，而是能解释、能降级、能回滚的生产能力。
别让错误假设进入生产
失败路径需要与成功路径共享同一套状态模型。只弹一个错误提示却不释放资源、不传播终态，下一次恢复就会继承脏状态。
- 部分模块仍直接调用 Date.now 会混入真实时间；推进一个大步若不按截止顺序执行会错过中间状态和重试次数。
- 只修正界面状态而没有清理底层资源，下一次操作继承队列、锁或过期凭据并再次失败。
- 指标标签直接包含用户或任务标识，既制造高基数成本，也让诊断数据泄露不必要的身份信息。
发布闸门应该检查什么
验证需要先写预期状态轨迹，再执行故障注入。每个阶段同时核对用户可见结果、两端协议状态、持久记录和资源计数，才能证明闭环成立。
- 覆盖闰秒无关、墙钟跳变、24 小时退避和同刻取消/超时竞争，重复运行必须生成字节级相同状态轨迹。
- 在操作中途断网、切换网络并恢复，核对两端状态、持久化记录和资源计数最终一致。
- 分别覆盖直连、中转、弱网、后台标签页和移动端，报告不能只给平均值或一次成功截图。
完成并不等于主路径跑通，而是每个终态都能对账、每个自动动作都受用户意图约束、每个成本都有明确上限。