windows的sleep和linux的nanosleep行为不一致，需手动处理信号中断、时间单位转换及0毫秒让出时间片；std::this_thread::sleep_for底层依赖系统api，精度和可靠性受平台影响，高实时场景须实测验证。
Windows下Sleep和Linux下nanosleep行为不一致怎么办？
Sleep在Windows是毫秒级、阻塞调用，参数为DWORD；nanosleep在POSIX系统需要struct timespec，且可能被信号中断返回-1。直接封装时若忽略中断重试，休眠时间会严重不足。
- 用
nanosleep必须检查返回值：返回-1且errno == EINTR时需重新传入剩余时间 - Windows的
Sleep(0)会主动让出时间片，Linux下nanosleep传0不会让出，得用sched_yield()模拟 - 不要用
usleep（已废弃）或select(nullptr, nullptr, nullptr, nullptr, &tv)（精度差、有副作用）
// 推荐的跨平台休眠核心逻辑（伪代码）
#ifdef _WIN32
Sleep(ms);
#else
struct timespec ts = {ms / 1000, (ms % 1000) * 1000000};
while (nanosleep(&ts, &ts) == -1 && errno == EINTR) {}
#endif
为什么std::this_thread::sleep_for不是万能解？
C++11起标准库提供std::this_thread::sleep_for，看似一劳永逸，但它底层仍依赖系统API，实际表现受编译器、标准库实现、内核调度策略影响：
MSVC + Windows：基于
Sleep，精度约15–16ms（系统时钟粒度）-
libstdc++（GCC）在Linux：多数版本用
nanosleep，但旧版glibc可能退化为select立即学习“C++免费学习笔记（深入）”；
libc++（Clang）：通常更贴近POSIX语义，但Android NDK等嵌入式环境可能阉割
若项目需严格≤1ms误差（如音频同步），不能只信
sleep_for，得实测clock_gettime(CLOCK_MONOTONIC, ...)前后差值在实时性要求高的场景，避免在循环里反复调用
sleep_for，累积误差可能达数毫秒
封装成函数时，哪些参数边界容易踩坑？
跨平台休眠函数最常错在毫秒参数的类型和范围处理：
用
int作参数：负值传给Sleep会触发未定义行为（Windows直接崩溃），nanosleep则返回EINVAL用
unsigned int：0是合法的，但大值如UINT_MAX在Linux会被截断为timespec.tv_sec溢出（导致休眠几百年）正确做法是限定输入范围，例如只接受
uint32_t且上限设为30 <em> 60 </em> 1000（30分钟），超出则报错或分段调用建议函数签名用
void platform_sleep_ms(uint32_t ms)，内部对0做快速路径（#ifdef _WIN32 Sleep(0); #else sched_yield(); #endif）不要试图支持“无限休眠”（如
INFINITE），那该用条件变量或事件对象
跨平台毫秒休眠真正难的不是写两行#ifdef，而是不同系统对“休眠完成”的定义差异——Windows说“至少睡这么久”，Linux说“尽量睡这么久，但信号随时能打断”。实测比文档可靠。
