Laravel 命令行执行超时，主要涉及两类场景：Artisan 命令本身运行超时（如 php artisan migrate、自定义命令），以及队列 worker 中的任务执行超时（如 php artisan queue:work）。两者机制不同，优化思路也不同。
Artisan 命令执行超时设置
Artisan 命令默认由 PHP CLI 模式执行，不受 Web 服务器或 FPM 超时限制，但会受 PHP 自身的 max_execution_time 影响（CLI 下默认为 0，即不限制）。
CLI 环境中
max_execution_time = 0是安全的，通常无需修改若你手动调用了
set_time_limit(60)或类似逻辑，反而可能意外中断长命令（如大数据导入、索引重建）-
真正需要关注的是：命令内部是否有阻塞操作未设超时？例如：
-
file_get_contents()未设流上下文超时 -
curl_exec()未配置CURLOPT_TIMEOUT或CURLOPT_CONNECTTIMEOUT - 数据库批量操作未分块，导致单次查询耗尽内存或锁表
-
✅ 推荐做法：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 移除命令中所有
set_time_limit()调用（CLI 下它既不必要也不可靠） - 对外部 HTTP 请求显式设超时：
$client = new \GuzzleHttp\Client(['timeout' => 10]); // 或原生 cURL： curl_setopt($ch, CURLOPT_TIMEOUT, 10);
- 大数据操作加
chunkById()或each()分批处理，避免 OOM 或 MySQL 超时 - 使用
--force或--no-interaction避免交互卡住（尤其在 CI/CD 中）
Laravel 队列 worker 执行超时优化
这是更常见的“命令行超时”问题——你以为是 Artisan 命令卡住，其实是 queue:work 进程里某个任务跑太久被杀。
-
php artisan queue:work是常驻进程，每个任务独立计时 - 超时由
--timeout参数或任务类$timeout属性控制，不是 PHP 全局设置
✅ 正确设置方式：
- 启动时指定（推荐用于环境隔离）：
php artisan queue:work --timeout=120 --tries=3
- 在任务类中声明（更灵活，支持动态覆盖）：
class ProcessReport { public $timeout = 300; // 5 分钟 public $tries = 3; } - 分发时临时覆盖：
ProcessReport::dispatch()->timeout(600)->delay(now()->addMinutes(5));
⚠️ 关键约束：
-
config/queue.php中对应驱动的retry_after必须 ≥timeout（建议至少 +10 秒） -
retry_after小于timeout会导致任务被重复消费（因 Redis/database 认为它“没完成”，而 worker 已杀掉它） - 不要用
set_time_limit()替代$timeout——在常驻进程中完全无效
监控与定位真实瓶颈
改超时只是掩耳盗铃。90% 的“超时”本质是某段代码或查询太慢。
✅ 实用监控手段：
- 在
App\Console\Kernel的schedule()或自定义命令中加入耗时记录：$start = microtime(true); // 执行耗时操作 $duration = round((microtime(true) - $start) * 1000); \Log::info('Command step X took', ['ms' => $duration]); - 对数据库操作加慢查询日志（MySQL
long_query_time=1）+ Laravel Telescope 或 Horizon 查看具体 SQL - 使用
strace -p $(pgrep -f 'queue:work')观察 worker 是否卡在系统调用（如epoll_wait、read）
不复杂但容易忽略
