php artisan schedule:run 没反应是因为Laravel调度器仅判断任务是否该执行，真正触发依赖系统Cron；需在部署用户crontab中添加定时命令，路径、PHP版本、时区、命令注册及日志配置均需正确。
为什么 php artisan schedule:run 没反应？
因为 Laravel 的调度器本身不运行任务，它只负责“判断该不该跑”，真正执行靠的是系统级 Cron。直接敲命令没效果，说明你还没在服务器上配置系统 Cron 来定期调用它。
- 必须在 Linux 服务器的 crontab 里添加一行：
* * * * * cd /var/www/your-app && php artisan schedule:run >> /dev/null 2>&1 -
cd路径必须准确，否则artisan找不到app/Console/Kernel.php，会报Class 'App\Console\Kernel' not found - 不要用
sudo crontab -e写到 root 的 cron 里，除非你的 web 服务也跑在 root 下；通常应改当前部署用户（如www-data或deploy）的 crontab - 如果用了 Envoy 或部署工具（如 Envoyer），注意部署后会覆盖 crontab —— 需在部署脚本末尾重新写入
Laravel schedulable 任务不触发的三个常见原因
你在 app/Console/Kernel.php 的 schedule 方法里写了 $schedule->command('inspire')->hourly()，但任务就是不跑，大概率卡在这几个点上：
- 时间表达式写错：比如用
->everyFiveMinutes()却忘了服务器时区是 UTC，而你本地是 CST ——php artisan tinker里执行now()->tz('UTC')和now()->tz('Asia/Shanghai')对比下 - 命令类没注册进容器：检查
app/Console/Commands/InspireCommand.php是否在app/Providers/AppServiceProvider.php的boot里绑定了，或者更简单——确认该类顶部有protected $signature = 'inspire'; - 任务被跳过：如果命令执行耗时超过 60 秒，Laravel 默认会跳过下一次（防堆积），可在调度链中加
->withoutOverlapping()或显式设超时->runInBackground()->timeout(120)
如何让定时任务支持失败重试和日志追踪？
默认 scheduled:run 出错了就静默吞掉，连错误都看不到。得主动加日志和兜底逻辑：
Laravel Cloud
下载
Laravel Cloud（cloud.laravel.com）。此技能用于处理所有 Laravel Cloud 请求，包括搜索和读取数据。只要任务涉及 Laravel Cloud，即使用此技能。
- 所有自定义命令必须 try/catch 包裹关键逻辑，并用
Log::error()记录异常，别依赖report()—— 它可能被环境关掉 - 重试不是 Laravel 调度器原生能力，得自己实现：比如在命令里加计数字段存 Redis，失败时
Redis::incr("retry:inspire:{$date}")，超过 3 次就发 Slack 告警 - 日志路径别硬编码，用
storage_path('logs/schedule-'.date('Y-m-d').'.log')，避免权限问题导致写入失败 - 如果用 Horizon 管理队列任务，注意
scheduler和queue:work是两套机制 —— 不要把本该走 schedule 的任务扔进队列再调度，会多一层延迟和失败面
上线后 Cron 任务突然变慢或漏跑？看这三点
本地跑得好好的，一上生产就出问题，基本逃不开资源、配置、路径这三块：
- 内存限制：系统 Cron 默认用
sh启动，不加载用户 profile，php可能用的是系统自带低版本（如 PHP 7.2），而项目要求 8.1 —— 在 crontab 里写死完整路径：/usr/local/bin/php81 - 磁盘满了：Laravel 调度器每次运行都会往
storage/logs/laravel.log写记录，如果没 logrotate，几个月下来几百 MB，schedule:run会卡在日志写入上 - 数据库连接池耗尽：多个定时任务同时查库，又没设
DB_CONNECTION=sqlite隔离，容易触发 MySQL 的Too many connections—— 给调度任务单独配个轻量 DB 连接，或加->onOneServer()限流
最常被忽略的是：crontab 编辑保存后不会自动 reload，改完必须等下一分钟才生效，别急着删日志验证 —— 先 sudo systemctl status cron 确认服务活着，再 grep CRON /var/log/syslog 看有没有调用记录。
