PHP脚本超时默认30秒，由max_execution_time控制；调大仅延后报错，不解决卡顿、死循环等根本问题。
PHP 脚本超时默认是 30 秒，max_execution_time 就是控制这个上限的。调大它确实能防止脚本被强制中止，但不等于“解决问题”——它只是把报错时间往后推，背后卡顿、死循环、慢查询等问题依然存在。
怎么改 max_execution_time（三种常用方式）
修改位置不同，生效范围也不同，选错地方就白改：
-
php.ini 全局配置：改
max_execution_time = 300（单位秒），重启 Web 服务（如sudo systemctl restart apache2或sudo systemctl restart php-fpm）才生效；适合长期稳定的长任务，比如后台导出 -
ini_set()运行时设置：在脚本开头加ini_set('max_execution_time', '300');，只对当前请求有效；注意：如果 PHP 是以php-fpm模式运行且php_admin_flag[disable_functions]禁用了ini_set，这行就无效 -
set_time_limit()动态重置：调用set_time_limit(300)会从当前执行点起重新计时 300 秒；多次调用会覆盖前一次，但不能设为 0（即不限时）在某些 SAPI（如 CGI）下会被忽略
为什么改了还是超时？常见失效场景
你以为改了 max_execution_time 就万事大吉，其实还有几层“超时”在暗处卡着你：
ucp-gateway-skill
下载
搜索商品、准备购物车、发布 UCP 个人资料，并通过 The Agent Times UCP Gateway 创建买家确认的商家结账流程。UCP Gateway 是面向支持 UCP 的电商平台构建的购物基础设施层，其核心为 Universal Commerce Protocol（通用商业协议）。
-
Web 服务器超时优先级更高：Nginx 默认
fastcgi_read_timeout是 60 秒，Apache 有Timeout指令；哪怕 PHP 允许跑 300 秒，Nginx 在 60 秒没收到响应就直接断连，返回504 Gateway Timeout -
PHP-FPM 配置覆盖：
php-fpm.conf中的request_terminate_timeout（如设为60s）会强行 kill 掉 worker，比max_execution_time更狠，且无法用ini_set()绕过 -
CLI 模式不走这个参数：命令行执行 PHP（
php script.php）默认不限时，max_execution_time设为 0 才有效；但很多开发者误以为 web 和 CLI 行为一致
max_execution_time = 0 到底能不能用？
设为 0 表示“不限制脚本执行时间”，听起来很爽，但实际要非常谨慎：
立即学习“PHP免费学习笔记（深入）”；
- Web 场景下基本不建议设 0：一个死循环或阻塞 I/O（比如没设 timeout 的
file_get_contents()）会让整个 worker 卡住，拖垮并发能力 - CLI 场景可用，但必须配合业务逻辑兜底：比如用
pcntl_signal()捕获中断信号，或自己实现分段处理 + 断点记录，避免单次执行无限膨胀 - 某些共享主机或云函数平台（如阿里云 FC、腾讯云 SCF）会硬性限制最大执行时长（如 300 秒），PHP 层设成 0 也没用，还会触发平台级强制终止
ini_set('max_execution_time', '0'); // CLI 可用，Web 不推荐
if (function_exists('set_time_limit')) {
set_time_limit(0); // 同上，注意是否被 disable_functions 禁用
}
真正关键的不是把数字调多大，而是弄清脚本卡在哪——是 MySQL 查询没加索引？是 cURL 请求没设 CURLOPT_TIMEOUT？还是递归太深没出口？max_execution_time 只是表象，别让它变成掩盖问题的遮羞布。
