std::chrono::steady_clock 是毫秒级计时器的正解，因其单调稳定、不受系统时间调整影响；应配合 duration_cast 转换为毫秒，避免 count() 除法和整数截断问题。
怎么用 std::chrono 做一个靠谱的毫秒级计时器
直接上手：别碰 clock() 或 time()，它们精度低、跨平台行为不一致；std::chrono 是 C++11 起唯一推荐方案，但得选对时钟类型和单位。
关键不是“怎么写”，而是“怎么选”——std::chrono::steady_clock 才是计时器正解，它不随系统时间调整跳变，不会因 NTP 同步突然倒退或快进。而 std::chrono::system_clock 适合打日志时间戳，不适合测耗时。
- 用
steady_clock::now()获取起点和终点，差值转成毫秒：用duration_cast<:milliseconds></:milliseconds> - 避免直接用
count()除以 1000 —— 不同平台底层周期不同，duration_cast才安全 - 别在循环里反复调用
now()测单次函数——开销虽小但会干扰真实耗时，尤其在高频场景下
duration_cast 转换失败？常见单位陷阱在这儿
现象：duration_cast<:milliseconds>(d).count()</:milliseconds> 返回 0，哪怕实际过了几十毫秒——大概率是用了错误的源类型，比如把 nanoseconds 直接 cast 到 milliseconds 却没考虑截断规则。
本质是整数截断：默认向下取整（向零），不是四舍五入。例如 999 微秒转毫秒就是 0。
立即学习“C++免费学习笔记（深入）”；
让 macOS 自动化像说话一样简单 —— 用代码控制你的 Mac，无需学习 AppleScript 系统要求 macOS 14+ (Sonoma) Python 3.9+ 需要开启：辅助功能 + 屏幕录制权限
- 要保留小数感？用
double类型转换：std::chrono::duration<double std::milli>(d).count()</double> - 想四舍五入到毫秒？先转到微秒再加 500，再 cast：
duration_cast<:milliseconds>(d + 500us)</:milliseconds> - 别混用字面量单位：
100ms是milliseconds，100'000us是microseconds，类型不同不能直接比较
定时回调怎么搞？C++ 没内置 “setTimeout”
标准库不提供异步定时回调，std::this_thread::sleep_for 是最轻量的阻塞等待方式，适用于单线程简单延时，比如命令行工具等几秒后退出。
但它卡住当前线程，不能当“后台计时器”用。真要非阻塞、可取消、多任务并行的定时器，得自己封装或依赖第三方（如 Boost.Asio 的 steady_timer）。
- 简单轮询检测：记录起始时间，每次循环用
steady_clock::now() - start >= 5s判断 - 注意别用
system_clock做判断依据——系统时间被修改会导致误触发 - 高精度需求（如音频同步）慎用
sleep_for，它只保证“至少睡这么久”，实际可能更长
Windows 上 steady_clock 真的稳吗？
VC++ 2015 及之后版本中，steady_clock 底层用的是 QueryPerformanceCounter，基本可靠；但老版本（如 VS2013）可能 fallback 到 GetTickCount64，有约 15ms 误差。
如果你必须支持旧编译器，或者发现计时抖动明显（比如同一段代码多次运行差出几毫秒），建议加一层校准逻辑：跑几次空循环测最小开销，再从结果里减去。
- Clang/GCC 在 Linux/macOS 下基本无坑，
steady_clock绑定CLOCK_MONOTONIC - 用
steady_clock::is_steady编译期检查（返回true），但别 runtime 依赖它做分支——所有标准实现都该返回 true - 别用
high_resolution_clock替代——它只是别名，不同平台可能指向system_clock，反而不稳
真正难的不是写对那三行 chrono 代码，而是意识到：计时器是否“准”，取决于你选的时钟语义，而不是数字看起来多精细。
