set_time_limit(0)在ThinkPHP中可能失效，因其被框架调度机制拦截，且受Nginx、PHP-FPM及PHP三层超时限制共同影响，需同步调整各层配置并优化代码负载。
为什么 set_time_limit(0) 在 ThinkPHP 中可能失效
ThinkPHP 默认启用 App::run() 的调度机制，底层会拦截 PHP 原生的超时控制。即使你在控制器里写了 set_time_limit(0)，若请求已进入框架的生命周期钩子（比如 app_init 或 path_info 解析阶段），实际执行前就可能被 SAPI 层（如 Apache 或 Nginx + PHP-FPM）强制中断，根本没机会走到你的代码行。
常见错误现象：Fatal error: Maximum execution time of 30 seconds exceeded 出现在 vendor/topthink/framework/src/think/App.php 附近，说明超时发生在框架初始化阶段，而非你写的业务逻辑里。
- 优先检查 Web 服务器配置：Nginx 的
fastcgi_read_timeout、PHP-FPM 的request_terminate_timeout必须大于你要设的值 - ThinkPHP 自身不接管
max_execution_timeini 设置，但会受其影响；建议在入口文件public/index.php最顶部加ini_set('max_execution_time', '0')，比在控制器里调用更早生效 - CLI 模式下不受 Web 超时限制，但需确认是否误用了 HTTP 入口（比如用 curl 调用 web 接口跑长任务）
大文件导出或批量处理时如何避免超时
典型场景：用 Db::chunk() 导出 10 万条数据，每 chunk 处理 500 条，但单次循环内做了大量字符串拼接或写文件操作，导致单个 chunk 耗时超过 30 秒。
关键不是“延长超时”，而是降低单次执行负载：
立即学习“PHP免费学习笔记（深入）”；
- 用
fopen(..., 'a')追加写入 CSV，避免file_put_contents($file, $data, FILE_APPEND)每次都打开/关闭文件 -
Db::chunk(500, function ($rows) { ... })中，不要在闭包里做dump()、Log::info()等 I/O 操作；改用计数器每 1000 行记一次日志 - 禁用查询日志：
Db::startTrans(); Db::getConfig('log_sql', false);防止 SQL 日志拖慢速度 - 如果必须用 Excel 导出，别用
PhpSpreadsheet在内存中构建整表，改用xlswriter扩展流式写入（支持writeSheetRow()）
PHP-FPM 和 Nginx 的 timeout 配置联动要点
ThinkPHP 是运行在 PHP-FPM 上的 Web 应用，超时是三层叠加的结果：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 或预期值
真正需要超时保护时该怎么设合理值
无限制（set_time_limit(0)）只适合离线脚本或可信后台任务。线上接口若允许无限执行，一个死循环或锁表查询就能拖垮整个服务。
推荐分层设限：
- Web 接口：保持默认 30 秒，用异步队列（如 think-queue）解耦耗时操作
- CLI 命令：在命令类
handle()开头加set_time_limit(600)（10 分钟），并配合pcntl_signal(SIGALRM, ...)做软中断 - 数据库操作：给
Db::execute()加timeout参数（TP6.1+ 支持），例如Db::connect(['timeout' => 120]) - 最易忽略的一点：Redis 或 HTTP 客户端超时独立于 PHP 执行时间，
Cache::store('redis')->set('key', $val, 3600)若 Redis 响应慢，也会卡住整个脚本
超时不是性能问题的遮羞布，它只是最后一道防线。真正要调的，是查询效率、缓存命中率和 I/O 方式。
