应使用 std::chrono::steady_clock 测量按键时间间隔，因其单调递增、不受系统时间调整影响；system_clock 可能回跳导致负值或异常大值，不适用于耗时测量。
std::chrono 里该用 steady_clock 还是 system_clock
按键时间间隔必须用 std::chrono::steady_clock，不能用 system_clock。前者是单调递增的物理时钟，不受系统时间调整（如 NTP 同步、手动改时间）影响；后者可能回跳或跳变，导致算出负间隔或异常大值。
常见错误：用 system_clock::now() 记录两次按键，结果在后台自动校时后得到 -30s 或 24h 的“间隔”。
-
steady_clock是唯一适合测量耗时的时钟，C++ 标准明确要求它“不被调整” - 它的
time_point类型不能直接转成“年月日”，但这对间隔计算反而是优点——避免隐式转换开销和歧义 - Windows 上它底层通常对应
QueryPerformanceCounter，Linux 上多为CLOCK_MONOTONIC，精度通常在纳秒级（实际取决于硬件）
如何捕获按键并避免阻塞主线程
标准 C++ 没有跨平台按键监听 API，std::cin.get() 或 getchar() 会阻塞，且无法区分“按下”和“释放”，也不支持非回显输入。真实场景需结合平台 API：
- Windows：用
GetAsyncKeyState(VK_SPACE)轮询，配合std::this_thread::sleep_for(1ms)控制采样频率，避免空转吃满 CPU - Linux：用
termios将终端设为 raw 模式，再读STDIN_FILENO，每次读到一个字节就记录时间点 - macOS：类似 Linux，但需注意
ioctl(TIOCSTI)不可用，推荐用kbhit()+getchar()组合（需自行实现或引入ncurses）
关键点：不要依赖 std::cin 的换行等待，否则第二次按键前用户必须按 Enter，测的就不是“按键间隔”而是“输入行间隔”。
立即学习“C++免费学习笔记（深入）”；
时间差怎么算才不会溢出或丢失精度
直接用 end_time - start_time 得到的是 duration 对象，但后续转换要小心：
- 别用
.count()后强制转double再除——例如(end - start).count() / 1000.0，若duration是纳秒级而你只想要毫秒，应先转换单位：std::chrono::duration_cast<:chrono::milliseconds>(end - start).count()</:chrono::milliseconds> - 避免链式 cast：比如从
nanoseconds先转microseconds再转milliseconds，中间可能截断；一步到位最安全 - 如果间隔可能超过数小时，用
std::chrono::duration<long long std::ratio>></long>（秒）或std::chrono::hours存储，防止int溢出（纳秒级count()在 2.9 小时就会超 int 最大值）
示例正确写法：
auto start = std::chrono::steady_clock::now();<br>// ... 等待按键<br>auto end = std::chrono::steady_clock::now();<br>auto ms = std::chrono::duration_cast<std::chrono::milliseconds>(end - start).count();
为什么测出来总是 0 或固定值
这不是 chrono 的问题，而是输入采集逻辑没对齐到“按键事件”本身：
- 轮询太慢（如每 50ms 查一次键状态），两次按键若都在同一轮询周期内被发现，差值就是 0
- 没做按键状态去抖：连续读到多次
GetAsyncKeyState非零，但实际是一次按下，应只取第一次上升沿 - 终端缓冲未关闭（Linux/macOS），导致按键被行缓冲拦住，直到回车才送达程序
- 测试时用 Shift/Ctrl 等修饰键——它们通常不触发字符输入，但部分 API 仍会报告状态变化，造成误计
验证方法：打印原始 time_point.time_since_epoch().count()，看数值是否随每次按键明显增长。如果全一样，说明根本没重新采样。
真正难的从来不是调用 steady_clock::now()，而是让“按键”这个事件被程序无延迟、无歧义地捕获到——chrono 只负责记，不负责听。
