应优先在php.ini中调高max_execution_time并重启php-fpm；cli环境默认不限时，但需检查启动参数；web下还需同步调整nginx fastcgi_read_timeout及php-fpm request_terminate_timeout。
PHP脚本超时被max_execution_time强制终止怎么办
ThinkPHP项目里跑定时任务、导出大数据或调用外部API时，脚本常在30秒后直接报错Fatal error: Maximum execution time of 30 seconds exceeded——这不是ThinkPHP的问题，是PHP底层的max_execution_time在截断。它默认30秒，且对CLI和Web SAPI行为不一致。
实操建议：
- Web环境（如Nginx+PHP-FPM）：优先在
php.ini里改max_execution_time = 300，改完必须重启PHP-FPM，只改ini_set('max_execution_time', 300)在某些FPM配置下会被忽略 - CLI环境（如
php think command:run）：命令行默认是0（不限时），但如果你用了php -d max_execution_time=30启动，就得同步调整该参数 - ThinkPHP自身不干预这个限制，别在
app/common.php里反复调用set_time_limit()，容易被后续代码覆盖或触发Cannot set time limit in safe mode（虽然现在基本不用safe_mode了）
为什么set_time_limit(0)在ThinkPHP里有时没用
不是函数失效，而是执行时机和SAPI模型导致的“看似无效”。比如在中间件或控制器方法开头写set_time_limit(0)，但请求已进入PHP-FPM的worker进程，而该进程可能已被上游（如Nginx的fastcgi_read_timeout）先杀掉。
关键点：
-
set_time_limit()只重置当前脚本剩余时间，不是全局开关；它从调用那一刻重新计时，不是从请求开始算 - 若使用Apache mod_php，
set_time_limit(0)通常生效；但PHP-FPM下，还需检查request_terminate_timeout（FPM pool配置），它比max_execution_time更早触发进程终止 - ThinkPHP的
think\exception\Handle不会捕获超时错误——这是PHP内核级致命错误，无法try/catch，日志里也只留半截堆栈
ThinkPHP命令行任务如何稳定绕过超时
运行php think export:data这类长任务，不能只靠调大max_execution_time，得组合控制。
推荐做法：
- 入口脚本第一行就加
set_time_limit(0)，别等框架初始化完再设 - 在
config/console.php里显式设置'default' => ['timeout' => 0]（部分版本支持），但注意这只是命令调度层逻辑，不替代PHP原生限制 - 避免在循环中频繁调用
echo或var_dump——某些终端或IDE（如PhpStorm的Terminal）会因输出缓冲阻塞，间接触发超时假象 - 如果任务涉及大量数据库写入，记得手动
$connection->startTrans()并分批commit()，否则MySQL连接可能先于PHP超时断开，报MySQL server has gone away
线上环境改max_execution_time要注意什么
改大不是万能解法，尤其在共享FPM池或容器化部署中。
真实风险点：
- 单个慢脚本占满FPM worker，导致其他请求排队，
pm.status_path里能看到active processes飙升但requests卡住 - Docker容器若没配
--memory限制，长时间运行可能OOM被kill，错误日志里只显示Killed，找不到PHP超时痕迹 - 云WAF或CDN（如Cloudflare）有自己独立的请求超时（常为100秒），即使PHP允许跑5分钟，前端早已返回504
- ThinkPHP日志驱动若用
File且并发高，flock()争抢可能导致写日志阻塞，间接拖慢整体，看起来像超时
真正难处理的，是那些既没报错、又没进度、CPU空转的“伪超时”——往往卡在DNS解析、SSL握手或第三方SDK的同步HTTP客户端里，这时候max_execution_time改再大也没用。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
