中等时间间隔的精确时间差：GetTickCount64与QueryPerformanceCounter对比

咱们针对你关心的几个主流Windows时间API，逐一拆解它们在小时级测量场景下的准确性问题：

一、QueryPerformanceCounter（QPC）：短时间好用，但小时级误差不可忽视 #

• QPC确实是短时间间隔测量的首选，但它的硬件计数器漂移误差最高可达500PPM，换算下来每小时会有2秒左右的误差，这对分钟到小时级的测量来说，偏差已经很明显了。
• 更头疼的是，哪怕是最新的处理器，依然有用户反馈碰到QPC的异常行为（比如计数跳变、跨CPU读取不一致）。微软只说推荐用在“短期测量”，但从来没明确过“短期”到底是几秒还是几十分钟，这种模糊定义对需要稳定小时级计时的场景来说，风险太高。

二、GetTickCount64：低精度但更稳定的替代，你的三个疑问解答 #

针对你提到的三个核心问题，实际情况是这样的：

1. 准确性对比与误差范围：
   官方确实没给出GetTickCount64的详细准确性数据，但从实际测试和社区反馈来看，它的误差来源是系统定时器的基础漂移，一般每小时误差在100毫秒到1秒之间，比QPC的2秒误差要更稳定。它的精度确实比QPC低（默认分辨率15.625ms），但小时级测量场景下，准确性反而更靠谱。
2. timeBeginPeriod对准确性的影响：
   timeBeginPeriod只能调整GetTickCount64的分辨率（比如把默认的15.625ms降到1ms），但不会改变它的准确性——准确性依然由系统定时器的漂移决定，调整分辨率只是让它的计数更新更频繁，不会修正时钟本身的偏差。
3. 是否单调且永不被调整：
   没错，GetTickCount64是单调递增且不会被调整的。它的计数基于系统启动后的累计滴答数，哪怕手动修改系统时间或者通过NTP校准系统时间，它也不会回退或跳跃，只会持续递增。文档里说它的分辨率不受GetSystemTimeAdjustment影响，本质就是因为它的计时逻辑和系统时间校准完全无关，只依赖启动后的硬件滴答。

三、GetSystemTimePreciseAsFileTime：禁用时间调整后的QPC升级版 #

当你通过SetSystemTimeAdjustment禁用自动时间调整后，GetSystemTimePreciseAsFileTime确实比直接调用QPC更有优势：

• 它本身就是基于QPC实现的，但微软在内部做了优化：比如处理了多CPU系统中不同核心计数器的偏移问题，避免跨CPU读取QPC导致的异常；还做了数据清理，过滤掉一些硬件计数器的噪声。
• 用它来测量本机时间差，能避开直接调用QPC时可能遇到的线程亲和性、计数器不一致等问题，稳定性比原生QPC更好。

内容的提问来源于stack exchange，提问作者aggieNick02