PHP 8.5.5 不存在，截至2026年6月官方最新稳定版为PHP 8.3，PHP 8.4处于RC阶段；所谓“8.5.5”是误标或自定义版本，超时问题根源在于PHP、FPM、Nginx三层超时配置叠加，而非版本本身。
PHP 8.5.5 不存在——你看到的这个版本号是误标或自定义编译产物。截至 2026 年 6 月，PHP 官方最新稳定版是
PHP 8.3，
PHP 8.4 处于 RC 阶段，尚未发布正式版，更不存在
PHP 8.5.5。你实际运行的，是某个具体版本（用
php -v 或
phpinfo() 确认），而所有超时行为都取决于该真实版本 + 运行环境配置，不是“8.5.5”本身导致的。
为什么改了 max_execution_time 还报 30 秒超时？
这不是配置没生效，而是你改错了地方，或者被更高优先级的限制覆盖了：
- Web 环境下（如 Nginx + PHP-FPM），
max_execution_time 只控制 PHP 脚本的 CPU 执行时间，不计 sleep()、fread()、curl_exec() 等 I/O 等待；真正卡住用户的，往往是这些阻塞操作
- FPM 池配置里的
request_terminate_timeout（单位秒）优先级高于 max_execution_time，设成 30 就算你在脚本里调 set_time_limit(0) 也无效
- Nginx 的
fastcgi_read_timeout 默认常为 60 秒，但它只管“从 PHP 收响应”的时间；如果 PHP 卡在数据库查询或远程请求上迟迟不返回，Nginx 先断连，前端报 504，PHP 错误日志里却可能没记录
-
php --ini 和 phpinfo() 显示的 “Loaded Configuration File” 路径必须一致——你编辑的 php.ini 很可能不是 Web 请求实际加载的那个
set_time_limit() 在循环里反复调用为啥不管用？
它不是“续命”，而是“重置倒计时”，且有硬性前提：
- 必须在超时发生前调用；一旦触发
Fatal error: Maximum execution time of X seconds exceeded，后续任何 PHP 代码（包括 set_time_limit()）都不会执行
- 每次调用都是从当前时刻起重新计时，不是累加；比如循环中每轮都
set_time_limit(30)，实际效果是“每轮最多跑 30 秒”，而非“总共跑 30 秒 × N 轮”
-
set_time_limit(0) 在 CLI 下安全，在 Web 环境下极易失控：FPM worker 被占满、服务器资源耗尽、用户已断开连接但进程还在跑
- 某些托管环境（宝塔、云函数、共享主机）会禁用或忽略
set_time_limit()，它只对 PHP 层有效，不触碰 Nginx/FPM/OS 层限制
大文件写入、数据库慢查、cURL 卡住，max_execution_time 为啥拦不住？
因为这些操作不消耗 CPU，PHP 的计时器根本不动：
-
file_put_contents($path, $huge_data) 卡在磁盘 I/O 上？不计入超时——max_execution_time 对本地文件操作完全无效
-
mysqli_query() 等锁表或网络延迟？需单独设 MYSQLI_OPT_READ_TIMEOUT，不是靠脚本总时长控制
-
curl_exec() 等待远端响应？必须用 CURLOPT_TIMEOUT_MS 和 CURLOPT_CONNECTTIMEOUT_MS，否则可能挂十几分钟
- 会话目录堆积几百万个文件？
session_start() 本身就会因扫描目录而超时，此时要禁用 session.gc_probability，迁移到 redis 存储
真正卡住你的，从来不是“PHP 版本”，而是三层叠加的超时控制：PHP 层（
max_execution_time）、FPM 层（
request_terminate_timeout）、Web 服务器层（
fastcgi_read_timeout）。漏掉任意一层，
set_time_limit() 就像给漏水的船不停补洞——洞太多，补不过来。
