先说一个核心判断：在宝塔面板里用 PHP 跑耗时任务，比如大文件导入、批量处理、爬虫调度，如果只是单纯去改 max_execution_time，那基本上是白费力气。问题压根不在 PHP 本身，而是 Web 请求这个上下文，天生就不适合做“长跑运动员”。真正靠谱的方案，是切换到 CLI 模式，再配合合理的超时配置。
为什么改 php.ini 的 max_execution_time 无效？
很多人不理解，为什么明明改了 max_execution_time，任务还是会被中断。其实，Web 模式下 PHP 是被 Nginx 或 Apache 管理的，实际受三重限制，缺一不可：
- Nginx 的
fastcgi_read_timeout，默认 300 秒。超时后直接断开连接，PHP 进程会被强制 kill。 - PHP-FPM 的
request_terminate_timeout，宝塔默认也是 300 秒。这个参数的优先级高于max_execution_time，它才是真正的“杀手”。 - 浏览器或客户端主动断连。比如 Chrome 60 秒没响应，就会提示“连接已重置”。
所以，即使你把 max_execution_time 改成 0 或 3600，只要上面任何一个环节超时，脚本依然会中断。这不是 PHP 配置的问题，是 Web 架构的天然限制。
用 CLI 模式执行耗时脚本的正确姿势
CLI 模式才是唯一可靠的方案。它绕过了 Web 服务器，由系统直接调用 PHP 解释器，Nginx 和 FPM 的超时限制根本管不到它。
具体操作上，有几点需要注意：
- 确保脚本开头有正确的 shebang：
#!/usr/bin/env php，或者写死宝塔 PHP 的路径，比如#!/www/server/php/82/bin/php。 - 在终端中直接运行：
/www/server/php/82/bin/php /www/wwwroot/example.com/task.php。这里有个关键点，必须用宝塔对应版本的 PHP 二进制，不要只写php，否则可能调用的是系统默认的旧版本。 - 如果要从 Web 触发，比如点击按钮开始任务，可以用
shell_exec()或proc_open()启动后台进程，并立即返回响应。例如：$cmd = '/www/server/php/82/bin/php /www/wwwroot/example.com/task.php > /dev/null 2>&1 & echo $!';
$pid = shell_exec($cmd); - 务必加上
> /dev/null 2>&1 &，否则 Web 进程会卡在等待 CLI 输出上，等于没解决问题。
立即学习“PHP免费学习笔记（深入）”；
宝塔环境下修改 PHP-FPM 和 Nginx 超时参数（仅限极少数必须 Web 同步执行的场景）
不推荐这种做法，但如果真有某个接口需要“撑住 10 分钟”，那得同步调整三层配置：
- PHP-FPM 配置：宝塔 → 网站 → 设置 → PHP 版本 → 配置文件，找到
request_terminate_timeout = 600（单位秒），取消注释并保存，然后重启 PHP-FPM。 - Nginx 配置：宝塔 → 网站 → 设置 → 配置文件，在
location ~ \.php$块内添加：fastcgi_read_timeout 600;
fastcgi_connect_timeout 600;
fastcgi_send_timeout 600; - PHP 脚本内仍需设置：
set_time_limit(600);，并且注意，不能在ini_set('max_execution_time', '0')之前被 FPM 截断。 - 需要警惕的是，这些改动会影响整个站点的 PHP-FPM worker，并发高时容易造成资源堆积。
后台任务必须考虑的收尾问题
CLI 脚本跑起来容易，但收尾才是真正的难点——没日志、没状态、崩溃无声，这些都是线上事故的高发区。
- 用
file_put_contents('/tmp/task.log', date('Y-m-d H:i:s') . " start\n", FILE_APPEND);记录关键节点，方便后续排查。 - 避免直接
exit()，改用register_shutdown_function()做清理工作，比如释放锁、标记任务完成。 - 使用
pcntl_fork()或nohup时，要注意子进程孤儿化风险。更稳妥的做法是，用宝塔计划任务 +curl或php命令触发，这样便于监控和重试。 - 如果任务涉及数据库，记得在 CLI 中显式设置时区：
date_default_timezone_set('Asia/Shanghai');。Web 和 CLI 的时区可能不一致，这是个容易踩坑的地方。
说白了，真正棘手的从来不是“怎么让它多跑一会儿”，而是“它跑完了吗？出错了没？下次还能自动续上吗？”——CLI 只是起点，状态管理、错误捕获、日志归档，一个都不能少。
