php max_execution_time未生效，因宝塔界面修改可能被站点配置中php_admin_value、php-fpm的request_terminate_timeout或nginx的fastcgi_read_timeout覆盖，需同步检查并修改这四层超时设置。
PHP 管理页面改 max_execution_time 为什么没生效？
宝塔面板里点开 PHP 设置 → 修改 max_execution_time 值 → 保存 → 重启 PHP，但脚本依然超时 30 秒，大概率是配置没落到实际生效的 php.ini 文件里。宝塔的「PHP 管理」界面改的是主配置文件（通常是 /www/server/php/{版本}/etc/php.ini），但某些场景下，PHP 会优先读取其他位置的 ini 文件（比如通过 php_admin_value 在站点配置中硬编码覆盖）。
- 先用
phpinfo()页面确认「Loaded Configuration File」路径，再检查该文件里max_execution_time是否真被改了 - 如果用了「网站 → 配置 → PHP 配置 → 自定义 php.ini 参数」，这里加的参数会以
php_admin_value max_execution_time 300形式写入站点的nginx.conf或apache.conf，优先级更高，会盖掉全局 php.ini 的设置 - 修改后必须重启对应 PHP 进程（不是重载 Nginx/Apache），否则变量不会刷新
用命令行直接改 php.ini 更可靠
图形界面容易漏看覆盖逻辑，直接编辑文件反而更可控。尤其当多个 PHP 版本共存、或启用了多站点不同配置时，手动定位目标 ini 更稳妥。
- 查当前 PHP CLI 和 Web 使用的是否同一份配置：
php --ini和phpinfo()对比「Loaded Configuration File」 - 常用路径：
/www/server/php/80/etc/php.ini（80 表示 PHP 8.0，按你实际版本替换） - 找到
max_execution_time = 30这一行，改成你需要的值（如300），注意不要留空格、不要加引号 - 改完执行
service php-fpm-80 reload（版本号要匹配），或者在宝塔面板里点「重启」PHP 服务
set_time_limit() 在脚本里能临时绕过限制吗？
可以，但有前提：PHP 必须没启用 safe_mode（已废弃，不用管），且 max_execution_time 是通过 php.ini 或 php_admin_value 设置的——如果它被 php_admin_flag 锁死（比如宝塔某些安全加固模板会加 php_admin_flag engine off 类似逻辑），set_time_limit() 就会失效。
-
set_time_limit(0)表示取消限制，但仅对当前脚本生命周期有效 - 如果 PHP 是以 CGI/FastCGI 模式运行（宝塔默认是 PHP-FPM），这个函数仍可生效；但若用了 opcache 且脚本已被缓存，修改可能不立即体现
- 注意：有些主机商或云平台会在网关层（如 Nginx 的
fastcgi_read_timeout）设硬性超时，哪怕 PHP 层允许跑 600 秒，Nginx 可能在 60 秒就断连，返回504 Gateway Timeout
改完还是超时？重点盯这三个地方
最大执行时间不是孤立参数，它和运行环境强耦合。光调 max_execution_time 不够，下面三处不一致，照样卡住。
- Nginx 配置里的
fastcgi_read_timeout（通常在站点配置或/www/server/nginx/conf/nginx.conf），必须 ≥ PHP 设置值 - PHP-FPM 池配置里的
request_terminate_timeout（路径如/www/server/php/80/etc/php-fpm.d/www.conf），这个值如果设了，会直接 kill 掉超时进程，优先级高于max_execution_time - MySQL 等外部服务的连接/执行超时（如
mysqli.connect_timeout、pdo_mysql.default_socket_timeout）也可能让脚本卡在 I/O 上，看起来像 PHP 执行超时
真正麻烦的从来不是改哪个数字，而是得同时核对 PHP、PHP-FPM、Web 服务器、数据库客户端四层 timeout 配置是否对齐。漏一个，前面全白调。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
