在 CentOS 环境里，PHP 日志出现执行超时，最常见的起点是脚本运行时间超过了 max_execution_time 的默认限制，通常只有 30 秒。要解决这类问题，不能只盯着一个配置项：有时改 php.ini 就够了，有时需要同步调整 PHP-FPM，有时则说明代码本身已经存在性能瓶颈。下面按排查顺序展开，帮助你判断当前场景该用哪种办法，避免一味拉长超时时间却没真正解决问题。
PHP 超时通常是怎么发生的
所谓 PHP 脚本超时，本质上是脚本执行时长超过了 PHP 配置里的 max_execution_time。在默认配置下，这个值通常是 30 秒，普通页面请求问题不大，但一旦遇到批量处理、复杂查询、文件操作或外部接口调用，就容易触发超时。
如果你的日志里频繁出现相关报错，第一步通常是先确认：这是单个脚本偶发超时，还是整个站点、某类任务持续超时。前者适合局部放宽，后者更适合从服务配置和代码性能两头一起看。
先改全局配置：调整 php.ini 的执行时间
最直接的做法，是修改全局 PHP 配置文件中的 max_execution_time。常见路径包括 /etc/php.ini，或者在 Apache 环境下使用 /etc/php/版本号/apache2/php.ini。
可以先打开配置文件：
sudo vi /etc/php.ini找到这一行后，把默认的 30 秒改成更适合当前业务的值，例如 300 秒：
max_execution_time = 300这一步适合处理整台机器上多数 PHP 请求都偏慢、或某类后台任务明确需要更长执行时间的情况。但它的影响范围是全局的，修改前最好先确认是否会放大慢请求积压的问题。
保存退出后，需要重启 Web 服务配置才会生效：
sudo systemctl restart httpd或者：
sudo systemctl restart nginx只影响单个脚本时，用 ini_set 更稳妥
如果你只想针对某个脚本临时放宽执行时间，而不影响其他请求，可以直接在脚本开头设置：
ini_set('max_execution_time', 300);这里的 300 可以替换成你需要的秒数。这种方式更适合定时任务、一次性数据处理、调试阶段，或者你已经明确知道只有某一个脚本需要更长的运行窗口。
它的优点是改动小、影响面可控；但如果多个页面或多个任务都在频繁超时，就不该继续靠单脚本兜底，而应该回头检查全局配置和执行链路。
使用 PHP-FPM 时，还要检查 request_terminate_timeout
很多 CentOS 服务器现在都跑在 PHP-FPM 模式下，这时仅仅修改 php.ini 往往还不够。因为 PHP-FPM 自己也有请求终止时间控制，关键参数是 request_terminate_timeout。
相关配置文件通常位于：
/etc/php-fpm.d/www.conf/etc/php/版本号/fpm/pool.d/www.conf
找到对应项，修改或补充为：
request_terminate_timeout = 300s这里的时间单位要保留 s。如果前面的 max_execution_time 已经调大，但请求依然在差不多的时间点被杀掉，通常就要优先怀疑这一层限制。
修改完成后，重启 PHP-FPM 服务：
sudo systemctl restart php-fpm频繁超时别只加时间，更该查性能瓶颈
如果脚本经常超时，单纯把 30 秒改成 300 秒，通常只是延后报错时间，并没有解决问题本身。更常见的根因包括：
- 循环中执行了大量数据库查询
- 外部接口响应过慢
- 脚本存在内存泄露或无效重复计算
- 代码里出现无限循环或接近死循环的逻辑
这种情况下，可以借助 Xdebug 或 Blackfire 这类性能分析工具，定位具体是哪个函数、哪段循环、哪次查询拖慢了整体执行时间。对于线上环境来说，先定位热点再决定是否延长超时，通常比直接放大限制更可靠。
配置改完仍无效，还要继续排查哪些层面
如果你已经调整了 max_execution_time 和 request_terminate_timeout，问题依旧存在，就要把排查范围扩大到系统和外部依赖层。
常见方向包括：
- 应用代码中的无限循环
- 第三方接口、数据库或下游服务响应过慢
- 服务器资源限制，例如
ulimit - systemd 层面的超时限制，例如
TimeoutStopSec
实操上可以按“先局部、再全局；先配置、再性能、再系统”的顺序推进。这样更容易判断究竟是 PHP 自身的执行时间限制，还是更深层的服务链路问题。
一套更实用的处理顺序
对于大多数场景，可以按下面的顺序处理：
- 先确认是单脚本问题还是全局问题。
- 全局问题先看
php.ini里的max_execution_time。 - 如果使用 PHP-FPM，再核对
request_terminate_timeout。 - 仍然频繁超时时，使用 Xdebug 或 Blackfire 查性能瓶颈。
- 最后再检查外部接口、系统资源和 systemd 限制。
这样处理的好处是，既能快速恢复业务，也能尽量避免把真正的慢点长期掩盖掉。
