php 8.5.5 不存在，当前最新稳定版为 8.3，8.4 处于 rc 阶段；实际版本需用 php -v 或 phpinfo() 确认，配置与超时行为均以真实版本为准。
PHP 8.5.5 不存在——你实际运行的很可能是 PHP 8.3 或 8.4，别按“8.5.5”查文档或设配置，否则白忙。
确认你真在跑 PHP 8.5.5？
运行 php -v 看输出。截至 2026 年 6 月，PHP 官方最新稳定版是 8.3，8.4 处于 RC 阶段，PHP 8.5.5 是测试分支名、误标或本地编译自定义版本。所有配置行为都取决于你真实运行的版本，不是你以为的版本。
- 用
phpinfo()页面里的 “Loaded Configuration File” 查 Web 环境加载的是哪个php.ini - CLI 下用
php --ini查实际生效的配置路径 - 如果看到
PHP 8.5.5出现在phpinfo()里，说明你用了非官方构建包，其max_execution_time行为可能与标准版不一致
max_execution_time 在 Web 和 CLI 下表现完全不同
这个配置项默认只限制 CPU 执行时间，不计 I/O 等待（如 mysqli_query()、curl_exec()、file_get_contents()），所以设了 120 秒，但一个慢查询卡住 3 分钟，它根本不会触发超时。
- Web SAPI（如 FPM）默认值通常是 30 秒，但真正起效的是
request_terminate_timeout（FPM pool 配置），它优先级更高，且会直接 kill worker 进程 - CLI 模式下
max_execution_time默认为 0（不限时），set_time_limit()才有意义；但若启用了opcache.enable_cli=1，某些 JIT 路径下set_time_limit()可能延迟生效 -
max_input_time控制请求体解析耗时（比如上传大文件、解析深层 JSON），和max_execution_time无关，别混用
set_time_limit() 不是“续命按钮”，而是“重置倒计时”
它从调用那一刻起重新计时，不是延长总时长。脚本已运行 28 秒，再调 set_time_limit(30)，最多还能跑 30 秒，不是 58 秒。
- 参数为 0 表示取消限制，但仅对当前进程有效；在 Web 环境中慎用，容易拖垮整个 FPM pool
- 不能缩短已有超时（
ini_set('max_execution_time', 30)后调set_time_limit(10)无效） - 在阻塞调用中（如
sleep(10)）不计时，但mysqli_query()卡住时，计时器照常走——除非 MySQL 自身超时未设 - 异步环境（Swoole、RoadRunner）或线程扩展（pthreads 已废弃）下完全不适用
Web 服务器层超时经常比 PHP 先动手
即使 PHP 没超时，Nginx 或 Apache 也可能先断连接，返回 504 Gateway Timeout 或 “Premature end of script headers”。这时你看不到 PHP 的 Fatal error，日志里只有 Web 服务器报错。
- Nginx 的
fastcgi_read_timeout必须 ≥ PHP 的max_execution_time，否则白配 - Apache 的
Timeout指令控制整个请求生命周期（含网络传输），建议设为 PHP 限值的 1.5 倍 - Cloudflare、CDN、负载均衡器也有独立超时策略，它们根本不看 PHP 内部设置
- 真正稳住执行时长，得三层齐控：PHP 层（
max_execution_time+set_time_limit()）、FPM 层（request_terminate_timeout）、Web 服务器层（fastcgi_read_timeout/Timeout）
最容易被忽略的是：I/O 类操作（数据库、HTTP 请求、文件读写）是否自身设置了超时。PHP 的 max_execution_time 对它们基本“睁一只眼”，必须单独配 mysqli_options($link, MYSQLI_OPT_CONNECT_TIMEOUT, 5)、stream_context_create(['http' => ['timeout' => 10]]) 这类底层超时，否则光调 set_time_limit() 没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
