首选std::this_thread::sleep_for()，c++11起跨平台安全；windows下sleep()单位为毫秒且会阻塞线程；高精度或非阻塞场景应改用定时器或事件循环。
Windows下用Sleep()最简单，但注意单位是毫秒
Windows API 提供的 Sleep() 函数直接可用，头文件是 Windows.h，参数单位是毫秒（不是秒），传 0 也会让出当前时间片——这点常被误以为“没效果”。
- 必须包含
#include <windows.h></windows.h>，否则编译报错identifier "Sleep" is undefined - 传入负数会触发未定义行为，实际可能 crash 或静默失败
- 它会阻塞当前线程，UI 程序里别在主线程调用，否则界面冻结
- 若需精确到微秒级延时（比如驱动或高性能循环），
Sleep()不够准，最小分辨率通常 10–15ms，受系统调度影响大
跨平台首选std::this_thread::sleep_for()，C++11起原生支持
标准库方案更安全、可移植，且语义清晰。依赖 <thread></thread> 和 <chrono></chrono>，单位用 std::chrono 类型表达，不容易写错。
C++ Code Review Master
下载
组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。
- 写法示例：
std::this_thread::sleep_for(std::chrono::seconds(2));或std::this_thread::sleep_for(std::chrono::milliseconds(500)); - 不依赖平台头文件，Linux/macOS/Windows 都能编译通过
- 底层仍可能调用系统 sleep，但封装屏蔽了差异；在某些实时系统或嵌入式环境里，需确认 STL 实现是否启用 pthread 或类似机制
- 不能在无 thread 支持的 freestanding 环境（如裸机 firmware）中使用
避免用usleep()或nanosleep()——已废弃或非标准
usleep() 在 POSIX.1-2008 中已被标记为废弃，glibc 2.26+ 默认不暴露（除非定义 _GNU_SOURCE）；nanosleep() 虽仍在 POSIX 中，但接口麻烦、需手动处理被信号中断的重试逻辑。
- 调用
usleep(1000)想延时 1ms？实际可能被四舍五入或忽略——很多实现最低只支持 10ms -
nanosleep()返回 -1 且errno == EINTR时必须重试，漏掉就导致延时严重不足 - C++ 项目混用 C 风格 sleep 容易引发命名冲突（比如和自定义
sleep()函数冲突）
需要高精度或非阻塞延时？别硬等，改用定时器或事件循环
真正需要“等待 100ms 后做某事”，又不想卡住线程，sleep_* 全都不合适。这时候该考虑异步机制。
- Windows 可用
SetTimer()+WM_TIMER消息，或CreateWaitableTimer() - Linux 常用
timerfd_create()配合epoll，避免轮询 - C++20 的
std::jthread+std::stop_token可配合条件变量实现可取消的等待，比死等灵活得多 - 游戏或音视频程序里，延时通常由主循环 delta-time 控制，硬 sleep 反而破坏帧率稳定性
std::this_thread::sleep_for() 就够了；只有维护老 Windows 项目且不能改编译选项时，才考虑 Sleep()。精度要求一上来，sleep 就该退场了。C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
