sleep() 会阻塞整个 PHP 进程，不可与 file_get_contents() 混用；后者必须显式设置 timeout 超时，否则可能无限等待；真需延时请求应改用前端定时、队列或异步方案。
sleep 会阻塞整个 PHP 进程，别和 file_get_contents 混用
直接说结论：sleep() 是同步阻塞调用，它会让当前 PHP 脚本暂停执行，期间无法处理任何网络 I/O（包括 file_get_contents() 的响应等待）。如果你写成先 sleep(5) 再 file_get_contents($url)，那总耗时至少是 5 秒 + 请求耗时；如果反过来，想“等请求返回后再睡”，但又没设超时，file_get_contents() 卡住时你根本等不到 sleep 那一步——脚本就挂在那里了。
file_get_contents 超时必须显式配置 context
file_get_contents() 默认没有超时限制，底层用的是 fopen() 流，不设 timeout 就可能无限等下去。必须通过 stream_context_create() 注入超时参数：
$opts = [
'http' => [
'timeout' => 3, // 单位：秒，注意这是连接+读取总超时
'method' => 'GET',
]
];
$content = file_get_contents('https://api.example.com/data', false, stream_context_create($opts));
常见误区：
-
timeout不是连接超时（connect timeout），而是整个请求生命周期上限，PHP 7.3+ 才支持拆分connect_timeout和timeout - 值设为
0表示无限等待，千万别这么干 - 如果目标服务响应慢但稳定，3 秒太激进，建议从
10开始调，再按实际压测结果下调
需要延时 + 请求组合？改用异步或分进程处理
真要实现“延迟几秒后再发请求”，有更靠谱的替代路径：
立即学习“PHP免费学习笔记（深入）”；
-
前端控制：用 JS 的
setTimeout()触发 AJAX，PHP 纯后端只管响应，不掺和时间调度 - Cron 或队列：把任务写入数据库/Redis，由定时脚本或 Worker 拉取执行，避免阻塞 Web 请求进程
- 多进程模拟（慎用）：用
pcntl_fork()派生子进程，父进程立即返回，子进程里 sleep + 请求 —— 但需确保 PHP 启用了 pcntl，且 Web 服务器（如 Apache）允许 fork
硬在单次 Web 请求里塞 sleep() + file_get_contents() 是反模式，既拖慢响应，又浪费 FPM worker 进程。
调试卡死时优先看 error_log 和超时日志
当发现请求“卡住”没返回，别急着重现，先查两处：
- PHP 错误日志里有没有
PHP Warning: file_get_contents(): ... failed to open stream: Connection timed out—— 有说明超时生效了；没出现，大概率是没设 timeout 或被其他中间件拦截 - Web 服务器 access log 中该请求的响应时间是否远超预期（比如 30 秒、60 秒），结合
max_execution_time设置判断是 PHP 脚本超时还是网络层卡死 - 用
curl -v手动测试目标 URL，确认不是 DNS 解析慢、SSL 握手卡、或对方服务本身异常
真正难排查的，往往是 timeout 值设了但被 ini_set('max_execution_time', 0) 覆盖，或者用了 set_time_limit(0) 却忘了它对流操作超时无影响。
