让一个应用的时钟走得更快

30 天的试用期要等 30 天才会到期，除非你能拨动时间。常见的建议是把系统时钟往前拨，这需要管理员权限，还会把机器上的其他所有程序一起拖走。这个工具改为只拨动一个进程。

能快多少

选择一个整数倍率。应用的时钟会从会话开始的那个时刻起，以真实时钟的这么多倍速度前进。

倍率	真实的一分钟变成	适用于
`x60`	一小时	每小时的任务、会话超时、令牌寿命
`x1440`	一天	每日翻篇，半小时跑完 30 天试用期
`x43200`	30 天的试用期	趁你读这段话的工夫，看着整个试用期结束
`x525600`	一年	年度续费、证书到期
`x1000000`	约 1.9 年	上限

# 从当前的真实时间开始，每分钟跑一天
chrono run "C:\apps\test.exe" --mode x1440

# 从选定的日期开始，并从那里加速
chrono run "C:\apps\test.exe" --at 2027-12-01T09:00:00 --mode x1440

# 反过来，让时钟完全静止
chrono run "C:\apps\test.exe" --mode frozen

一段会话驱动另一个 Windows 应用的录屏。左侧窗口是 Chrono Mock，应用的时钟停在 2038-01-19 并以六十倍真实速度攀升，旁边的真实时钟只走了几秒。右侧窗口是被测应用，它自己的会话记录显示它从 2038-01-19 开始，已经运行了好几分钟，而现实中才过去不到半分钟。 — 一次真实的会话，驱动着一个真实的应用。请看右侧的窗口：被测程序把自己的启动记录为 **2038 年 1 月 19 日**，它的会话已经持续了几分钟，而房间里的时钟只走了几秒。速度是在运行时改变的，不需要重启任何东西。

容易让人栽跟头的地方：时钟有两个

加快挂钟时间——也就是 DateTime.Now 及其同类返回的值——本身并不会加快倒计时。这是应用可以向操作系统提出的两个不同的问题，而很多软件是用后者而不是前者来衡量“三十天”的。

所以时长轴——滴答计数、休眠、等待和定时器——是一个单独的开关：

--scale-duration 也会把滴答计数、休眠和定时器放到会话时钟上，而对象等待只计数并保持真实时长。没有它时，x1440 让日历飞快前进，而五秒的定时器仍然要花真实的五秒 - 只有设定在某个日期和时间的定时器在每个会话中都跟随会话时钟。
--scale-qpc 额外缩放高分辨率计数器。Python 3.13+ 的 monotonic、.NET 的 Stopwatch 和 Java 的 nanoTime 都是从这里读取经过的时间，它默认关闭，因为在测试中缩放它会让渲染不稳定。

如果倍率看起来对倒计时毫无作用，几乎总是这个原因。

# 计时器应用：日历和倒计时一起加速
chrono run "C:\apps\Timer.exe" --mode x60 --scale-duration

# 用高分辨率计数器测量经过时间的 Python 或 .NET 应用
chrono run "C:\apps\Job.exe" --mode x60 --scale-duration --scale-qpc

不重启就改变速度

倍率可以在会话中途改变，时钟是被重新锚定而不是跳变的，所以速度降低时它绝不会倒退。你也可以直接让时钟跳转——向前，或者像笔记本与时间服务器重新同步后那样向后，这正是会破坏任何没有保护措施地测量经过时间的东西的情形。

# 以 x60 运行，两秒之后切换到 x1440
chrono run "C:\apps\test.exe" --mode x60 --set-after 2:1440

# 运行，五秒之后把时钟跳到选定的时刻
chrono run "C:\apps\test.exe" --jump-after 5:2028-01-01T00:00:00

它不会做的事

它不会动系统时钟。这是重点，而不是局限——但这意味着任何从服务器、数据库或另一台机器读取时间的东西都不会受影响，出现这种情况时审计会告诉你。
跳转改变的是应用程序看到的内容，而不是它何时醒来。已经交给内核的休眠和定时器会保持设定时得到的时长。大多数应用程序会轮询时钟，所以跳转在实践中有效 - 但并非全部。
它不会让时间变慢。倍率是一及以上的整数，外加零倍率的冻结时钟。

这一切是否到达了你的应用，不应该靠假定。会话会告诉你 →

亲自试试

下载 Windows 版阅读常见问题