首选std::this_thread::sleep_for()，C++11起跨平台安全；Windows下Sleep()单位为毫秒且会阻塞线程；高精度或非阻塞场景应改用定时器或事件循环。

Windows下用Sleep()最简单，但注意单位是毫秒

Windows API 提供的 Sleep() 函数直接可用，头文件是 Windows.h，参数单位是毫秒（不是秒），传 0 也会让出当前时间片——这点常被误以为“没效果”。

• 必须包含 #include <Windows.h>，否则编译报错 identifier "Sleep" is undefined
• 传入负数会触发未定义行为，实际可能 crash 或静默失败
• 它会阻塞当前线程，UI 程序里别在主线程调用，否则界面冻结
• 若需精确到微秒级延时（比如驱动或高性能循环），Sleep() 不够准，最小分辨率通常 10–15ms，受系统调度影响大

跨平台首选std::this_thread::sleep_for()，C++11起原生支持

标准库方案更安全、可移植，且语义清晰。依赖 <thread> 和 <chrono>，单位用 std::chrono 类型表达，不容易写错。

• 写法示例：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 中，但接口麻烦、需手动处理被信号中断的重试逻辑。

C++ Code Review Master

组合式C++代码评审方案，融合静态分析、AI推理、多轮迭代评审和C++专项检查，适用于PR审查、增量代码审查、全项目评审和代码质量评分，触发词包括review cpp、cpp代码评审、C++review、代码审查。

下载

• 调用 usleep(1000) 想延时 1ms？实际可能被四舍五入或忽略——很多实现最低只支持 10ms
• nanosleep() 返回 -1 且 errno == EINTR 时必须重试，漏掉就导致延时严重不足
• C++ 项目混用 C 风格 sleep 容易引发命名冲突（比如和自定义 sleep() 函数冲突）

需要高精度或非阻塞延时？别硬等，改用定时器或事件循环

真正需要“等待 100ms 后做某事”，又不想卡住线程，sleep_* 全都不合适。这时候该考虑异步机制。

立即学习“C++免费学习笔记（深入）”；

• Windows 可用 SetTimer() + WM_TIMER 消息，或 CreateWaitableTimer()
• Linux 常用 timerfd_create() 配合 epoll，避免轮询
• C++20 的 std::jthread + std::stop_token 可配合条件变量实现可取消的等待，比死等灵活得多
• 游戏或音视频程序里，延时通常由主循环 delta-time 控制，硬 sleep 反而破坏帧率稳定性

实际写业务代码时，95% 场景用 std::this_thread::sleep_for() 就够了；只有维护老 Windows 项目且不能改编译选项时，才考虑 Sleep()。精度要求一上来，sleep 就该退场了。