macos 的 usleep() 受 mach timer 分辨率限制（约 10–15ms），实际延时常达 10ms 以上，linux 更接近设定值；两者均可能被信号中断，高负载下 macos 的 timer coalescing 会进一步增大延迟。
PHP 的 sleep() 和 usleep() 在 macOS 和 Linux 下行为基本一致，但底层调度精度、信号中断响应和高负载下的实际延时偏差可能不同——这不是 PHP 实现差异，而是操作系统内核调度机制导致的。
macOS 与 Linux 对 sleep() 的底层处理差异
PHP 的 sleep() 最终调用的是 libc 的 sleep(3)（秒级）或 nanosleep(2)（微秒/纳秒级），而这两个系统调用在 macOS（XNU 内核）和 Linux（CFS 调度器）上的实现细节不同：
- Linux 的
nanosleep()通常能提供更紧致的调度唤醒，尤其在低负载、启用CONFIG_HIGH_RES_TIMERS的内核上 - macOS 的
nanosleep()受 Mach timer 分辨率限制（默认约 10–15ms），即使传入usleep(1000)（1ms），实际休眠可能被拉长到 10ms 以上 - 两者都可能被信号（如
SIGALRM、SIGHUP）提前中断，此时sleep()返回剩余秒数，usleep()返回-1并设errno = EINTR
实测延时偏差：什么时候会明显感觉到不一样
你只有在以下场景才可能观察到 macOS 和 Linux 的差异：
- 循环中高频调用
usleep(1000)做“伪实时”轮询（比如监控文件变化、简易限频）→ macOS 下实际间隔可能跳变为 10–20ms，Linux 更接近 1–2ms - 使用
pcntl_signal()注册了信号处理器后调用sleep()→ macOS 更容易触发EINTR中断，需显式重试 - 系统负载高 + 有其他实时进程抢占 CPU → macOS 的 timer coalescing 机制会主动合并定时器唤醒，进一步放大延迟
示例：在 macOS 上运行 usleep(500) 100 次，用 microtime(true) 统计总耗时，常测得 15–25ms；Linux 同样代码多为 5–8ms。
立即学习“PHP免费学习笔记（深入）”；
跨平台写法建议：别依赖精确微秒级休眠
若业务逻辑对延时敏感（如协议握手超时、硬件同步），不要直接靠 usleep() 精确卡点。可行方案包括：
- 用
stream_select()配合空 socket 或STDIN做带超时的阻塞等待（兼容性好，精度由系统 select 实现决定，macOS/Linux 差异较小） - 对必须用休眠的场景，改用自适应循环：
while (microtime(true) ，避免单次调用过短被系统吞掉 - 生产环境做定时任务，优先走系统 cron / systemd timer / launchd（macOS），而非 PHP 内部 sleep 循环
- 调试时加日志：用
microtime(true)包裹usleep()前后，确认实际耗时，而不是相信参数值
真正棘手的不是 sleep() 函数本身，而是你以为它“睡够了”，结果发现 macOS 上醒来时已经晚了 10ms——而这个偏差在开发机（Linux）上完全测不出来。
