std::chrono::high_resolution_clock 并非总提供纳秒级精度，其实际精度取决于平台：Windows 通常基于 QueryPerformanceCounter，Linux 多用 CLOCK_MONOTONIC，但旧内核或容器中可能降级；应先检查 period::den 确认分母（如 10⁹ 表示纳秒），跨平台稳定计时推荐 steady_clock；time_point 相减得 duration，需显式转换才能获取秒数。
std::chrono::high\_resolution\_clock 真的“高精度”吗？
它不总是你想要的“最高精度”，取决于平台和编译器实现。Windows 上 high_resolution_clock 通常等价于 steady_clock（基于 QueryPerformanceCounter），Linux 上多数是 clock_gettime(CLOCK_MONOTONIC)，但某些旧内核或容器环境可能回落到 CLOCK_REALTIME 或更粗粒度源。
- 别硬写
high_resolution_clock::now()就以为能测纳秒级差异——先用high_resolution_clock::period::den查实际分母（比如1000000000表示纳秒，1000000就只是微秒） - 跨平台稳定计时优先选
steady_clock：它保证单调、不跳变，且在主流平台都提供微秒级或更好精度 - 若真要纳秒级测量（如性能 benchmark），得配合多次采样 + 排除异常值，单次
now()调用开销本身就在几十纳秒量级
time\_point 相减为什么得到的是 duration，而不是秒数？
time_point 是时间轴上的一个点，相减后得到的是两个点之间的“跨度”，类型是 duration，不是浮点秒。直接打印或参与计算前必须显式转换。
- 错误写法：
auto diff = end - start; std::cout —— 输出可能是 <code>123456 nanoseconds，但无法直接用于 if 判断或数学运算 - 正确做法：用
duration_cast转成你需要的单位，例如duration_cast<microseconds>(diff).count()</microseconds>得到微秒整数，或duration_cast<seconds>(diff).count()</seconds> - 注意精度损失：从
nanoseconds转milliseconds会截断，用round<seconds>(diff)</seconds>或floor<seconds>(diff)</seconds>更可控
std::chrono::system\_clock::to\_time\_t 为什么有时返回负值或错乱时间？
本质是时区与 epoch 对齐问题。system_clock 的 epoch 是 UTC 时间 1970-01-01 00:00:00，但 to_time_t 返回的是 time_t（通常为 signed int 或 long），在 32 位系统上会于 2038 年溢出；更常见的是你在本地时区构造 time_point 后没做 UTC 校准。
- 典型错误：用
system_clock::now()直接转time_t再传给localtime—— 没问题；但若你手动构造了time_point（比如加了偏移），却忘了它是 UTC 基准，就容易错 - 安全做法：需要本地时间显示时，先转
time_t，再用localtime_r（POSIX）或_localtime64_s（MSVC）转结构体，避免localtime的线程不安全 - C++20 起推荐用
zoned_time和sys_time处理时区，但目前主流项目仍以system_clock + time_t为主流兼容方案
std::this\_thread::sleep\_for 为啥有时睡得比预期长？
操作系统调度精度限制 + 睡眠唤醒开销导致的必然现象。sleep_for 只保证“至少睡这么久”，不保证精确唤醒时刻。
立即学习“C++免费学习笔记（深入）”；
- Windows 默认调度周期约 15.6ms（受
timeBeginPeriod影响），Linux 的CLOCK_MONOTONIC虽然更准，但进程调度延迟仍可能达毫秒级 - 不要用
sleep_for(1ms)做高频轮询——改用条件变量或 eventfd；若必须短延时，考虑std::this_thread::yield()配合 busy-wait（仅限极短、确定场景） - 调试时发现睡眠明显偏长？检查是否启用了省电模式（如 Windows 的“节能计划”）、CPU 频率缩放，或进程被降权（nice 值低）
真正难的不是调用哪个函数，而是搞清每个 clock 的行为边界：steady 不等于快，high_resolution 不等于稳定，system_clock 不等于本地时间。这些细节在嵌入式、高频交易或实时日志场景里，差几毫秒就能让排查变成噩梦。
