不管用。脚本超时后PHP已中止，set_time_limit无法再执行；它仅在超时前调用有效，且只计CPU时间，不计I/O等待，外层服务器超时更优先。
PHP 脚本超时后 set_time_limit 还管用吗？
不管用。一旦脚本执行时间超过 max_execution_time（或已触发的 set_time_limit 限制），PHP 会直接中止脚本，后续任何 PHP 代码（包括 set_time_limit）都不会再执行。
常见错误现象：Fatal error: Maximum execution time of X seconds exceeded 报错后，register_shutdown_function 可能运行，但 set_time_limit 已无意义——它只能在超时发生前调用才有效。
- 必须在脚本运行中、超时发生前调用，不能放在可能耗时的逻辑之后
- CLI 模式下默认为 0（不限时），但 Web SAPI（如 Apache、FPM）受
php.ini中max_execution_time初始值约束 - 每次调用
set_time_limit(n)都是「从当前时刻起」重置为 n 秒，不是累加
为什么在循环里反复调用 set_time_limit(0) 很危险？
这不是“续命”，而是放弃超时保护，极易导致进程卡死、资源耗尽。尤其在 FPM 下，一个失控的 set_time_limit(0) 可能占满 worker 进程，阻塞其他请求。
使用场景：仅适用于明确可控的长期任务（如离线数据导出），且必须搭配主动退出机制（如检查文件是否写完、队列是否清空）。
立即学习“PHP免费学习笔记（深入）”；
-
set_time_limit(0)后仍需手动检测中断信号（如pcntl_signal_dispatch()）或业务条件，否则无法响应 Ctrl+C 或 Nginx 超时断连 - 某些托管环境（如共享主机、部分云函数）会忽略
set_time_limit，强制以更短时间终止 - CLI 下生效，但 Docker 容器若配置了
timeout或livenessProbe，PHP 层面的设置仍会被外层截断
set_time_limit 对系统调用和 I/O 等待是否计时？
不计。PHP 的执行时间只统计脚本实际在 Zend 引擎中运行的 CPU 时间，sleep()、fread() 等阻塞操作、MySQL 查询等待、cURL 网络响应等都不计入超时判定。
这意味着：一个脚本可能“看着没动”，却始终不触发超时；也可能在密集计算中几秒就炸。
- 数据库慢查询、远程 API 响应延迟、大文件读取 —— 这些都逃得过
set_time_limit，但会让用户感知为“卡死” - 真正需要防护这类场景，得靠各层超时：PDO 的
PDO::ATTR_TIMEOUT、cURL 的CURLOPT_TIMEOUT_MS、Redis 的timeout参数 - 用
microtime(true)手动打点 + 循环内判断，比依赖set_time_limit更可靠（尤其混合 I/O 和计算的逻辑）
Web 环境下改 set_time_limit 为什么有时没效果？
因为服务器中间件（Nginx、Apache）或负载均衡器（ALB、Cloudflare）早已先一步切断了连接。PHP 层面的超时只是最后一道防线，常被外层拦截覆盖。
典型表现：PHP 设置了 set_time_limit(300)，但浏览器 60 秒就收到 504 Gateway Timeout —— 错不在 PHP。
- Nginx 默认
fastcgi_read_timeout 60，需同步调大；Apache mod_php 下看TimeOut，FPM 下看request_terminate_timeout - Cloudflare 免费版硬性限制 100 秒，再怎么调 PHP 也没用
- 即使所有超时都放宽，PHP-FPM 的
pm.max_requests或内存限制（memory_limit）也可能提前终结进程
set_time_limit 只是拼图一角，漏掉 Nginx、DB、网络任一环，它就形同虚设。 
