laravel任务调度需外部cron每分钟调用schedule:run；生产环境必须配置系统cron，检查crontab条目、权限及app_env=production；command()启新进程适合重逻辑，call()直接执行闭包但易中断；多服务器需ononeserver()+redis锁防重复；时区以config/app.php为准，须清配置缓存。
Laravel 任务调度不是“配完就能跑”，它必须依赖外部每分钟调用 schedule:run 才能生效；本地开发可临时用 schedule:work，但生产环境必须走系统 Cron。
为什么 schedule:run 没反应？先查这三件事
常见现象是任务写了、php artisan schedule:list 能看到，但到了时间完全没输出、日志里也没记录。根本原因往往不在代码，而在调度入口没打通：
-
crontab -e里是否真加了那一行？内容必须是：* * * * * cd /path/to/project && /usr/bin/php artisan schedule:run >> /dev/null 2>&1（注意：用绝对路径/usr/bin/php，不是php） - 执行 Cron 的用户（通常是
www-data或root）是否有权限读取项目目录、写storage/、加载.env？ -
APP_ENV是不是production？Laravel 在非 production 环境下会静默跳过所有调度逻辑——哪怕你手动运行schedule:run也不会触发任务
command() 和 call() 到底该选哪个？
这不是风格问题，而是执行模型差异导致的行为断层：
-
$schedule->command('backup:db')：启动全新 Artisan 进程，走完整命令生命周期（中间件、异常处理器、日志通道、队列连接），适合有 DB 事务、邮件发送、队列分发等重逻辑的任务 -
$schedule->call(function () { cache()->put('last_run', now()); })：直接在当前schedule:run进程内执行闭包，无进程开销，但一旦抛出未捕获异常，整个调度流程中断；且无法使用--no-interaction等命令参数，也不能访问 request/session 上下文 - 错误示范：
call()里调用了需要 Laravel 命令容器注入的 service，或用了$this->info()—— 终端不会输出，日志也不进laravel.log
多服务器部署时任务重复执行怎么办？
withoutOverlapping() 默认靠文件锁（storage/framework/cache/data/ 下的缓存项）实现，只对单机有效。如果应用跑在多个实例上（如 Kubernetes Pod 或负载均衡后），每个节点都会独立执行 schedule:run，结果就是每天发 5 遍邮件、清 5 次缓存。
- 最轻量解法：改用 Redis 锁，配合
cache()->store('redis')->lock()手动控制临界区，但需自己处理锁释放和续期 - 更稳方案：用
onOneServer()+ Redis 缓存驱动（必须配置CACHE_DRIVER=redis），它底层基于 Redis 的原子操作实现分布式锁，比手写更可靠 - 终极隔离：把调度服务单独拆成一个容器或机器，其他所有 Web 实例的 Cron 全部注释掉，只留这一台跑
schedule:run
时区错乱、时间不准？别只看服务器时间
服务器时区是 UTC，你在 schedule() 里写 ->dailyAt('02:00')，任务就会在 UTC 02:00（即北京时间 10:00）跑——因为 Laravel 调度器解析 cron 表达式时，只认 config/app.php 里的 'timezone' => 'Asia/Shanghai'，不认 date_default_timezone_set()，也不受系统 timedatectl 影响。
- 改完
config/app.php的timezone，必须执行php artisan config:clear，否则缓存旧值 - 避免在闭包里用
now()做判断——它返回的是服务器本地时区时间，和调度器用的时区可能不一致 - 测试时用
php artisan schedule:test --event="backup:db"（Laravel 9.25+）模拟触发，绕过时间校验，比等一整晚靠谱
真正容易被忽略的点是：调度器本身不维护状态，它每分钟都从头读取 Kernel.php 并重新计算该不该跑。所以任何影响这个“重新计算”的因素——比如配置缓存没清、APP_ENV 错误、闭包里引用了已销毁的容器绑定——都会让任务看似“随机失效”。
