Laravel定时任务需由系统Cron每分钟调用php artisan schedule:run来触发调度器判断执行时机;command()执行已注册命令,call()直接调用闭包但绕过异常处理;队列任务需单独运行queue:work进程。
Laravel 的定时任务不是靠 Cron 直接调用 PHP 脚本,而是靠一个固定运行的 artisan schedule:run 命令来触发调度器判断是否该执行——这点不搞清,所有配置都会失效。
php artisan schedule:run 必须由系统 Cron 每分钟执行一次因为 Laravel 的 Schedule 类本身不监听时间,它只在 schedule:run 被调用时检查当前时间是否匹配你定义的 ->everyMinute()、->daily() 等规则。没有外部轮询,调度器就是个“哑巴”。
常见错误现象:
php artisan schedule:run 手动跑一次能成功,但之后再也不执行->dailyAt('09:00') 却总在凌晨 00:00 执行(其实是没配 Cron,手动运行时碰巧时间满足)正确做法:
* * * * * cd /var/www/myapp && php artisan schedule:run >> /dev/null 2>&1
cd /var/www/myapp),不能用 ~/myapp
which php,避免 Web SAPI 的 php-fpm 路径混入)$schedule->command() 和 $schedule->call() 的本质区别
前者执行一个已注册的 Artisan 命令(必须继承 Illuminate\Console\Command),后者直接调用闭包或静态方法,适合简单逻辑但无法使用命令行参数、选项或输出重定向。
使用场景对比:
command('backup:database'):适合需复用、带参数(如 --force)、要记录日志或支持队列的任务call(function () { ... }):仅用于调试或极轻量操作(比如写一行日志),上线环境应避免——它绕过命令生命周期,不触发 handle() 外的事件、中间件、异常处理器
注意:call() 中抛出的异常不会被 Laravel 的命令异常处理器捕获,可能静默失败。
Laravel 调度器默认同步执行任务。即使你在 command() 里用了 dispatch(new SomeJob),那个 Job 仍是在 schedule:run 进程中 dispatch 的——如果队列驱动是 sync,它立刻执行;如果是 redis 或 database,它只是写入队列表,但没人消费。
关键点:
php artisan queue:work --daemon(Laravel ≤ 8)或
php artisan queue:work(Laravel ≥ 9,默认已 daemon 化)
queue:work 进程和 schedule:run 是两个独立进程,互不依赖schedule 里写 $schedule->job(new MyJob)->daily() ——这是无效写法,job() 方法只在 Laravel 5.5–5.7 存在且已被移除别等 Cron 分钟级触发,也别改系统时间。直接用 schedule:run 加 --pretend 参数看它“打算”运行什么:
php artisan schedule:run --pretend
输出类似:
Running scheduled command: "/usr/bin/php" "artisan" "inspire" >> "/var/www/myapp/storage/logs/cron.log" 2>&1
说明规则已加载、时间判断逻辑正常。再配合 --verbose 可看到跳过原因(比如 “Not due yet” 或 “Disabled by environment”)。
容易被忽略的坑:
APP_ENV=local 时,schedule:run 默认不执行任何任务(除非你显式调用 ->when(true)),这是 Laravel 内置保护机制php artisan config:clear 后忘记 config
:cache,会导致 App\Console\Kernel.php 中的 schedule() 方法未被加载Log::info() 却没看到日志?检查 storage/logs/ 权限,或确认日志通道是否配置为 daily 导致当天日志文件名含日期