1. 为什么我们需要精确的时间戳在开发高性能应用时时间戳的精度往往决定了程序的可靠性。想象一下你在开发一个在线游戏服务器玩家A声称自己先击中了玩家B但服务器记录的两次命中时间差只有几毫秒。如果使用秒级精度的时间戳你根本无法判断谁先谁后。这就是为什么我们需要毫秒甚至微秒级的时间戳。Windows平台开发者最熟悉的可能是GetTickCount64()这个API。它用起来非常简单返回的是系统启动后经过的毫秒数。我在一个网络同步项目中第一次用它时发现它有个特点不受系统时间修改的影响。这意味着即使用户故意把系统时间调前GetTickCount64()的返回值仍然会正常递增。不过这里有个坑GetTickCount64()不会计算系统休眠的时间。我曾在笔记本上测试过一个需要长时间运行的程序发现唤醒后时间差和实际休眠时间对不上。如果你需要计算真实流逝的时间可能需要考虑其他方案。2. Windows专属方案深入理解GetTickCount64GetTickCount64()是Windows平台最常用的毫秒级时间获取方式。它的原型很简单#include windows.h ULONGLONG GetTickCount64(void);我在性能测试工具中使用它时发现它的调用开销极小通常只需要几个CPU周期。这对于需要频繁获取时间的场景特别重要。比如在游戏循环中每帧都要获取多次时间来计算delta time这时候GetTickCount64()的高效性就体现出来了。但要注意几个限制精度通常是15.6毫秒取决于系统时钟分辨率最大值约49.7天2^64毫秒不计算系统休眠时间我曾在一个服务程序中使用它来计算运行时长结果用户休眠笔记本后再打开发现运行时间统计少了几个小时。后来改用QueryPerformanceCounter才解决了这个问题。3. 跨平台的基础方案time(NULL)当我们需要简单的秒级时间戳时C标准库的time函数是最便携的选择#include ctime time_t now time(NULL);这个函数返回的是从1970年1月1日UNIX纪元至今的秒数。我在写跨平台日志系统时经常用它因为所有平台都支持而且足够记录大多数事件的发生时间。不过它有三个明显的不足只有秒级精度受系统时间影响2038年问题32位系统记得有一次调试一个分布式系统不同机器因为时间不同步用time(NULL)生成的时间戳完全乱了套。后来我们改用NTP同步时间并在关键处使用了更高精度的计时方式。4. 现代C的终极方案std::chronoC11引入的chrono库彻底改变了时间处理的方式。它提供了类型安全、高精度、可扩展的时间操作。我最喜欢它的三点清晰的类型系统区分不同时间单位可以轻松转换时间单位高精度时钟支持获取当前时间并转换为毫秒的典型用法#include chrono #include iostream int main() { auto now std::chrono::system_clock::now(); auto ms std::chrono::time_point_caststd::chrono::milliseconds(now); auto value ms.time_since_epoch(); std::cout value.count() ms since epoch\n; return 0; }chrono库提供了三种时钟system_clock可转换为日历时间受系统时间影响steady_clock单调时钟适合测量时间间隔high_resolution_clock最高精度的时钟在开发一个高频交易模拟器时我对比过这三种时钟的性能。steady_clock在保证单调性的同时精度也能达到微秒级最终成为了我的选择。5. 实战场景下的选择建议不同的应用场景需要不同的时间方案。根据我的经验可以这样选择游戏开发帧计时steady_clock或QueryPerformanceCounter游戏逻辑时间GetTickCount64()仅Windows或steady_clock服务器开发日志时间system_clock需要日历时间性能统计steady_clock超时检测GetTickCount64()Windows或clock_gettimeLinux嵌入式系统硬件定时器直接读取考虑使用RTOS提供的时间API我曾参与一个跨平台游戏引擎的开发最终我们抽象了一个时间层在Windows下使用QueryPerformanceCounter在其他平台使用clock_gettime在接口层统一成类似std::chrono的用法。6. 精度与性能的权衡高精度时间获取通常意味着更高的性能开销。在我的测试中i7-9700K方法平均耗时(ns)精度time(NULL)151秒GetTickCount64()18~15毫秒std::chrono::now()35100纳秒QueryPerformanceCounter221微秒对于需要每秒上万次调用的场景这个开销差异就很关键了。我的建议是先确定需要的精度在满足精度前提下选择最快的方案必要时缓存时间值在开发一个粒子系统时我最初每粒子每帧都获取时间后来改为每帧只获取一次时间性能提升了近20%。7. 常见陷阱与解决方案陷阱1时钟回退当用户修改系统时间时system_clock获取的时间会回退。我在开发一个定时器系统时遇到过这个问题导致本该触发的定时器一直不触发。解决方案关键逻辑使用steady_clock陷阱2精度不足GetTickCount64()的默认精度只有15.6毫秒不够精确。解决方案调用timeBeginPeriod提高系统时钟分辨率陷阱3跨平台差异不同平台的高精度时钟实现不同。解决方案使用std::chrono并测试目标平台的实际精度陷阱4整数溢出32位系统上time_t在2038年溢出GetTickCount64约49.7天溢出。解决方案定期检查差值而不是直接比较绝对值记得有一次线上服务崩溃就是因为没处理GetTickCount64的溢出当服务连续运行50天后时间计算全部出错。后来我们改为总是计算时间差并处理可能的溢出情况。8. 高级技巧与最佳实践时间测量模板templatetypename F auto measure_time(F f) { auto start std::chrono::high_resolution_clock::now(); f(); auto end std::chrono::high_resolution_clock::now(); return end - start; }时间点缓存 对于不要求精确时间但频繁调用的场景可以每帧/每100ms缓存一次时间值。自定义时钟 对于特殊需求如游戏暂停可以封装自定义时钟类。日志时间格式化auto now std::chrono::system_clock::now(); auto t std::chrono::system_clock::to_time_t(now); std::cout std::put_time(std::localtime(t), %F %T);跨平台封装#ifdef _WIN32 using HighResClock std::chrono::steady_clock; #else using HighResClock std::chrono::high_resolution_clock; #endif在最近的一个项目中我们需要支持Windows、Linux和Mac三个平台还要保证时间测量的一致性。最终我们基于std::chrono做了封装在Windows下额外处理了时钟精度的设置在Linux下特别处理了时钟源的选择取得了不错的效果。