用 std::chrono::steady_clock 测量耗时最安全，它不随系统时间跳变而抖动，适合性能统计、超时控制等场景，但无法转换为可读时间；system_clock 因受 NTP 等影响会导致耗时计算异常。
直接结论：用 std::chrono::steady_clock 测量耗时最安全，它不随系统时间跳变而抖动，适合所有性能统计、超时控制、频率调度类场景；但不能转成可读时间（比如“2026-07-27 18:25”），这点必须提前接受。
为什么不能用 system_clock 测执行时间？
系统时间可能被手动修改、NTP 同步或夏令时调整——system_clock::now() 返回的值会突然回退或前跳。一旦你用它算函数耗时，就可能出现负值、零值、甚至几十秒的“幻觉延迟”。
常见错误现象：
- 程序在测试机上耗时稳定，上线后某天凌晨突然报告“耗时 -2345ms”
- 容器环境里 NTP 频繁校准，
system_clock统计的响应时间毛刺密集
这不是 bug，是设计使然：system_clock 表达的是“墙上时间”，不是“流逝时间”。
立即学习“C++免费学习笔记（深入）”；
steady_clock::time_point 怎么记、怎么减？
它本质是一个“滴答计数器”，从某个未公开的起始点开始单调递增。你不需要知道起点在哪，只管取差值：
auto start = std::chrono::steady_clock::now(); // ... 执行逻辑 auto end = std::chrono::steady_clock::now(); auto elapsed = end - start; // 类型是 duration，不是浮点数
关键点：
-
elapsed是std::chrono::steady_clock::duration类型，不能直接.count()输出——必须先显式转换单位 - 别写
elapsed.count()，它返回的是纳秒级整数（可能溢出或难读），应配合duration_cast - 推荐写法：
std::chrono::duration_cast<:chrono::milliseconds>(elapsed).count()</:chrono::milliseconds>
high_resolution_clock 和 steady_clock 到底该选谁？
标准没强制规定 high_resolution_clock 的底层实现，MSVC 常把它 alias 成 steady_clock，GCC/Clang 有时 alias 成 system_clock。这意味着：
- 跨平台项目里用
high_resolution_clock，可能在 Windows 上稳定，在 Linux 上受系统时间干扰 - 如果你只关心“这段代码跑了多久”，
steady_clock是唯一可移植、可预期的选择 -
high_resolution_clock的“高精度”不等于“高可靠性”——纳秒级精度若叠加跳变，反而更危险
简单说：除非你明确需要纳秒级分辨率且已验证目标平台行为，否则一律用 steady_clock。
单位转换和浮点精度陷阱
直接用 duration_cast 转整数类型（如 milliseconds）会截断，丢失亚毫秒信息；想保留小数，得用浮点 duration：
// 截断式（推荐用于日志、阈值判断） auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(elapsed).count(); <p>// 浮点式（需注意精度损失） auto ms_f = std::chrono::duration<double, std::milli>(elapsed).count(); // 约 6 位有效数字
容易踩的坑：
- 用
double表示纳秒级大数值（比如运行几小时）会丢失精度——double只能精确表示 ≤2⁵³ 的整数 - 别对
time_point做加减以外的运算（比如乘除），它没有物理意义 -
steady_clock的time_since_epoch()没业务含义，不要试图打印或存储它
真正需要长期存档的时间戳，必须用 system_clock；而所有中间过程的计时、等待、限频，只认 steady_clock——这个边界模糊了，问题就藏不住了。
