ThinkPHP报Maximum execution time exceeded的脚本运行超时调优

不少开发者都遇到过这种情况：在ThinkPHP里明明写了set_time_limit(0)，可脚本还是掐着点儿就挂了。报错信息里赫然一行“Maximum execution time of 30 seconds exceeded”，位置偏偏指向vendor/topthink/framework/src/think/App.php——连业务代码的门都没摸着，就被强行中断了。

这背后的原因，其实和ThinkPHP的调度机制有关。框架默认启用了App::run()生命周期，底层会拦截PHP原生的超时控制。即便你在控制器里调用了set_time_limit(0)，请求一旦进入框架的初始化钩子（比如app_init或path_info解析阶段），SAPI层——也就是Nginx加上PHP-FPM——可能就直接把你拦在门外了，代码根本跑不到你想保护的那一行。

那么，解决思路其实很清楚，需要从几个层面入手：

• 先检查Web服务器配置，Nginx的fastcgi_read_timeout和PHP-FPM的request_terminate_timeout必须大于你要设定的时间。
• ThinkPHP本身不接管max_execution_time，但会受它的影响。建议在入口文件public/index.php的最顶部加上ini_set('max_execution_time', '0')，这个时机比在控制器里调用要早得多。
• CLI模式下通常不受Web超时限制，但得确认你是否误用了HTTP入口。比如通过curl来调用Web接口跑长任务，那就等于自己给自己上套了。

真正到了大文件导出或者批量处理的场景，问题的关键反而不是“延长超时”，而是想办法降低单次执行的负载。举个例子，用Db::chunk()导出10万条数据，每500条处理一次，但每次循环里如果做了大量字符串拼接或者文件读写，单次chunk耗时很容易超过30秒。

优化方向其实很明确：

• 用fopen(..., 'a')追加写入CSV，避免file_put_contents每次都重新打开关闭文件。
• 在Db::chunk的闭包里，尽量别做dump()、Log::info()这类I/O操作。改成计数器，每1000行记一次日志就足够了。
• 禁用查询日志，用Db::startTrans()配合Db::getConfig('log_sql', false)，防止SQL日志拖慢速度。
• 如果非要导出Excel，别在内存里用PhpSpreadsheet构建整张表。改用xlswriter扩展做流式写入，性能差距非常明显。

还有一个容易踩的坑，就是超时配置的联动效应。ThinkPHP跑在PHP-FPM上，超时实际上是三层叠加的结果：Nginx、PHP-FPM、PHP内部。任意一层先触发，报错信息都差不多，很容易误判。

必须同步检查并调大三处：

• Nginx那边：fastcgi_connect_timeout 300;、fastcgi_send_timeout 300;、fastcgi_read_timeout 300;（单位都是秒）。
• PHP-FPM的pool配置：request_terminate_timeout = 300，注意不是php.ini里的max_execution_time。
• PHP-FPM全局：process_control_timeout = 300，防止管理进程误杀worker。
• 验证也很简单：在控制器里分别输出echo get_cfg_var('max_execution_time');和echo ini_get('max_execution_time');，确保两者都显示0或者你预期的值。

最后想说的是，无限制执行真的只适合离线脚本或者可信的后台任务。线上接口如果允许无限跑，一个死循环或者锁表的查询就能把整个服务拖垮。

推荐的做法是分层设限：

• Web接口保持默认30秒就够了，耗时的操作交给异步队列（比如think-queue）去解耦。
• CLI命令可以在handle()开头加set_time_limit(600)，配合pcntl_signal做软中断，更安全。
• 数据库操作可以给Db::execute()加上timeout参数（TP6.1+支持），比如Db::connect(['timeout' => 120])。
• 别忘了Redis或者HTTP客户端超时独立于PHP执行时间。如果Cache::store('redis')->set()遇到Redis响应慢，照样会卡住整个脚本。

说到底，超时设置只是最后一道防线。真正值得花功夫去调的，是查询效率、缓存命中率、还有I/O方式。防线再牢，底子差了也扛不住。