最可靠方式是用同一clock（如steady_clock）获取时间点后相减得duration，再用duration_cast转毫秒；混用clock类型编译报错，steady_clock适合测间隔，system_clock可转真实时间但受系统时间调整影响。
用 std::chrono 计算毫秒级时间差最可靠
直接用 std::chrono::steady_clock 或 std::chrono::system_clock，别碰 time() 或 clock() —— 前者精度低、后者测的是 CPU 时间，不是真实流逝时间。
常见错误是混用不同 clock 类型做减法（比如 system_clock::now() - steady_clock::now()），编译不过；或者用 duration_cast 时选错单位导致截断（比如用 seconds 去接毫秒级差值，小数部分全丢）。
实操建议：
- 测代码执行耗时，一律用
std::chrono::steady_clock（不随系统时间调整跳变） - 记录绝对时间点（如日志打点），用
std::chrono::system_clock - 差值转成整数前，先确认
duration_cast的目标类型能容纳结果，比如duration_cast<milliseconds>(end - start).count()</milliseconds> - 避免用
time_t手动算秒差——跨 DST、闰秒、时区会出错
std::chrono::duration 的 count() 返回什么
返回的是该 duration 内部“滴答数”（tick count），具体数值取决于底层时钟的周期。比如 milliseconds 的 count() 就是毫秒整数；nanoseconds 的 count() 是纳秒整数。它不是浮点秒数，也不是相对时间戳。
立即学习“C++免费学习笔记（深入）”；
容易踩的坑：
- 直接打印
duration对象（如cout ）可能输出不可读格式，必须用 <code>.count()提取数字 -
count()返回rep类型（通常是long long），但若差值超范围会溢出，大间隔建议用duration_cast<seconds></seconds>先降级 - 不能对两个不同单位的 duration 直接比较大小（比如
ms > us），必须先统一 cast 到同一单位
Windows 下 GetTickCount64() 能不能替代 chrono
能，但不推荐作为通用方案。它返回自系统启动起的毫秒数，类型是 ULONGLONG，64 位下不会溢出（约 500 年），精度通常为 10–16ms（取决于系统设置），且只在 Windows 可用。
对比 chrono：
-
GetTickCount64()启动快、调用开销略低，适合高频打点但不要求亚毫秒精度的场景 -
std::chrono::steady_clock::now()在主流平台（Win/Linux/macOS）行为一致，精度通常达微秒级，可移植性好 - 混用二者计算差值会出问题：比如把
GetTickCount64()值直接塞进milliseconds构造函数，没考虑其实际分辨率
跨天/跨年的时间差怎么算（比如 2024-01-01 到 2024-12-31）
别用 chrono 的 system_clock::time_point 直接减——它只给总纳秒差，不提供“多少年多少月”这种日历语义。要算日历差，得用第三方库（如 Howard Hinnant 的 date 库）或系统 API。
例如用 date 库：
#include <date/date.h>
auto d1 = date::year_month_day{2024_y/1/1};
auto d2 = date::year_month_day{2024_y/12/31};
auto diff = date::years{d2.year()} - date::years{d1.year()}; // 得到 0y
// 真正的日历差需用 date::days 或 date::months
关键提醒：C++20 引入了 <chrono></chrono> 日历支持（year_month_day 等），但很多编译器（如 GCC 12）尚未完全实现；生产环境仍建议用 date 库或 strftime/strptime 配合 mktime 手动处理。
最容易被忽略的一点：所有基于系统时间的计算，都受本地时区和夏令时影响。如果业务逻辑要求 UTC 时间差，务必用 system_clock::to_time_t + gmtime，而不是直接用 localtime。
