C++推荐使用std::this_thread::sleep_for跨平台延时。需包含<thread>和<chrono>，用毫秒等字面量避免精度丢失；Windows用Sleep（毫秒，大写），Linux/macOS用nanosleep（纳秒级）；禁用usleep和小写sleep。
C++ 没有标准的 sleep 函数，直接写 sleep(1000) 在不同平台会编译失败或行为不一致。
Windows 下用 Sleep（注意大小写）
Windows API 提供的是首字母大写的 Sleep，单位是毫秒，需包含 windows.h。它会阻塞当前线程，但不释放 CPU——这点常被误认为“卡死”，其实只是线程挂起。
- 必须加
#include <windows.h>，否则报错identifier "Sleep" is undefined -
Sleep(0)是合法的，会让出当前时间片，适合忙等优化 - 传入负数或超大值（如
Sleep(-1)）不会报错，但行为未定义，实际可能立即返回或挂起极长时间 - 跨平台代码里混用
Sleep和sleep（小写）会导致 Linux 编译不过
Linux/macOS 用 nanosleep 而不是 sleep
POSIX 标准下，sleep（小写）只接受秒级整数，精度太低；真正可控的是 nanosleep，支持纳秒级，且能处理被信号中断的情况。
- 用
sleep时，若程序收到信号（如SIGINT），可能提前返回，且返回剩余秒数——很多新手忽略这个返回值，导致延迟不准 -
nanosleep需要构造struct timespec，例如{1, 500000000}表示 1.5 秒；第二个参数非空时可接收被中断后剩余时间 - 不要用
usleep：已被标记为废弃（obsolete），glibc 中可能未来移除
C++11 起统一用 std::this_thread::sleep_for
这是最推荐的方式：跨平台、类型安全、语义清晰。底层自动调用各系统原生 API，无需条件编译。
立即学习“C++免费学习笔记（深入）”；
- 必须
#include <thread>和<chrono>，否则编译失败 - 单位用
std::chrono::milliseconds(1500)这类字面量，别手算毫秒数再传 int——容易溢出或精度丢失 - 不能在 detached 线程里无脑调用：如果主线程结束而该线程还在 sleep，程序可能提前终止，
sleep_for不会阻止进程退出 - 调试时注意：IDE 断点可能停在 sleep 期间，但实际时间流逝不受影响，别误判“断点卡住了”
延迟执行 ≠ 定时任务，别把 sleep 当调度器用
所有基于 sleep 的延迟都是“阻塞式等待”，一旦需要并发多个延迟动作、或中途取消，就必须换方案（如 std::async + std::future::wait_for，或事件循环）。
- 循环中反复
sleep做轮询（比如每 100ms 查一次文件是否存在）效率低，且无法响应外部中断 -
std::this_thread::sleep_until看似高级，但依赖系统时钟稳定性；若系统时间被 NTP 调整，可能跳过或重复触发 - 嵌入式或实时场景慎用：sleep 不保证唤醒时间精度，硬实时需求得用专用 RTOS 的定时器
真正麻烦的从来不是“怎么睡”，而是“睡完之后要不要继续、谁来叫醒、醒了发现条件没满足怎么办”。这些逻辑一加，sleep 就只是最底层的一行调用而已。
