PHP脚本超时需三层协同控制：脚本内set_time_limit()、PHP运行时max_execution_time配置、Web服务器（如Nginx/Apache）超时设置；任一层缺失都会导致超时失效。
PHP 脚本超时不是靠“设个开关”就能稳住的，它分三层控制：脚本内硬性中断、Web 服务器拦截、PHP 运行时配置限制。漏掉任何一层，set_time_limit(30) 都可能被绕过或失效。
用 set_time_limit() 在代码里动态设上限
这是最常用也最容易误用的方式。它从调用点开始重新计时，不是从脚本启动算起；而且在 safe_mode（已废弃）或 disable_functions 包含它时会直接报错。
- 参数为
0表示取消时间限制（危险，慎用） - 参数为正整数（如
60）表示最多再运行 N 秒，不是“总时长” - CLI 模式下默认不限制，但 Web 模式受
max_execution_time初始值约束 - 如果脚本正在执行系统调用（如
sleep()、file_get_contents()网络请求），部分版本 PHP 不会计时——实际耗时远超设定值
set_time_limit(10); // 后续代码最多还能跑 10 秒，超时抛出致命错误：Fatal error: Maximum execution time of 10 seconds exceeded
max_execution_time 是 PHP-FPM / Apache 的硬门槛
这个 ini 配置项才是多数 Web 场景下的真正闸门。它在脚本启动时就生效，比 set_time_limit() 更早介入，且无法被用户代码关闭（除非有权限改 php.ini 或 .htaccess）。
- Apache + mod_php 下可通过
.htaccess修改：php_value max_execution_time 20 - PHP-FPM 中建议在 pool 配置里设：
php_admin_value[max_execution_time] = 15（避免被脚本覆盖） - CLI 执行时该值默认为
0（不限制），所以php script.php可能跑很久而 Web 请求早就 504 了 - 注意单位是秒，不是毫秒；设太小会导致正常 API 响应被截断
Web 服务器层还会再拦一次：Nginx 和 Apache 不认 PHP 的“自我管理”
即使 PHP 自己没超时，前端服务器也可能先杀掉连接。这时你看到的不是 PHP 错误，而是 504 Gateway Timeout 或 Apache 的 “Premature end of script headers”。
立即学习“PHP免费学习笔记（深入）”；
- Nginx 默认
fastcgi_read_timeout是 60 秒，必须 ≥ PHP 的max_execution_time，否则白设 - Apache 的
Timeout指令（非max_execution_time）控制整个请求生命周期，包括网络传输，建议设为 PHP 限值的 1.5 倍 - Cloudflare、CDN、负载均衡器也有自己的超时策略，它们根本看不到 PHP 内部逻辑
真要稳住执行时长？得组合打补丁
单靠一个函数或配置，解决不了真实场景里的超时漂移。比如一个循环里调用外部 API，网络卡顿 30 秒，set_time_limit() 根本救不了。
- 对可拆分任务，改用队列（如 Redis + Worker）+ 异步回调，避开 Web 请求生命周期
- 耗时操作中主动调用
microtime(true)做分段校验，比依赖全局超时更可控 - 用
pcntl_alarm()（仅 CLI）发信号中断，但不适用于 FPM/CGI 环境 - 监控日志里搜
"Fatal error.*execution time"和 Nginx 的"upstream timed out"，两者不一致说明某层配置脱节
超时从来不是“设个数字”就完事的事——它是 PHP 配置、Web 服务、网络链路、业务逻辑四者咬合的结果。少对齐一层，就多一个超时黑盒。