web 请求中直接调用 sleep() 会导致 php worker 进程空转阻塞，无法处理其他请求，高并发时耗尽 worker 引发 502/504 错误，且受 nginx fastcgi_read_timeout 等代理层超时限制。
PHP 的 sleep() 函数确实能暂停脚本执行，但它在 Web 环境下几乎总是错的用法 —— 它会阻塞整个请求进程，浪费服务器资源，还可能触发超时或被代理中断。
Web 请求中直接调用 sleep() 会导致什么
在 Apache + PHP-FPM 或 Nginx + PHP-FPM 架构下，sleep(5) 不是“让这个页面等 5 秒”，而是让当前 PHP Worker 进程空转 5 秒，期间无法处理其他请求。如果并发高，很快耗尽 worker 数量，新请求排队甚至 502/504。
- 浏览器看到的是白屏卡顿，不是“加载中”状态
- NGINX 默认
fastcgi_read_timeout是 60 秒，sleep(70)直接报 504 - Cloudflare、CDN 层也可能主动断开长连接
-
set_time_limit(0)不能绕过 Web 服务器自身的超时限制
真正需要延时的常见场景和替代方案
多数想用 sleep() 的需求，其实要的是「延迟响应」或「定时触发」，而非阻塞当前脚本：
-
模拟接口响应延迟（测试用）：改用开发环境的反向代理（如 nginx 的
return 200+add_header）或前端 mock 工具，不走 PHP -
轮询等待后台任务完成：后端立即返回任务 ID，前端用
setTimeout()或fetch()轮询/api/task/status?id=xxx -
发送邮件/短信后延时重试：把重试逻辑交给消息队列（如 Redis
zadd+ 定时消费者），或数据库记录下次执行时间，由 cron 脚本扫描 -
CLI 脚本中的真实延时：只有命令行运行（如
php script.php）才适合sleep()，且建议配合pcntl_signal()处理中断
sleep() 和 usleep() 的关键区别与风险
sleep() 参数单位是秒（整数），usleep() 是微秒（整数，最大约 21 亿 ≈ 2.1 秒）。两者都受 max_execution_time 限制，且在 CLI 下生效，在 Web 下极易踩坑：
立即学习“PHP免费学习笔记（深入）”；
-
sleep(0)不等于“不睡”，它会触发一次系统调度，实际消耗几毫秒 -
usleep(1000000)=sleep(1)，但精度更高；不过 Web 环境下仍无法保证精确到微秒级 - 若脚本启用了输出缓冲（
ob_start()），sleep()期间不会刷新内容，用户看不到任何进度 - 在 PHP 8+ 中，
sleep()可被信号中断（如SIGUSR1），需检查返回值是否为 0
真要在 Web 中做可控延时，优先考虑异步机制：Swoole 的 co::sleep()（协程内无阻塞）、ReactPHP 的 Loop::addTimer()，或者干脆把延时逻辑推给前端。PHP 的 sleep() 是个“看起来简单，实际危险”的函数，用之前先问自己：这个暂停，真的必须由 PHP 进程来扛吗？
