Laravel应用在CPanel共享服务器上每日Cron Job调度失效问题排查

我来帮你梳理这个问题的排查思路，这种在共享主机上的调度差异很常见，咱们一步步来定位：

1. 先纠正Laravel调度的语法错误 #

你提到用了$schedule->command('alert:dailly')->cron('0 0 * * * *');——这里有个明显的错误：Cron表达式是5个字段（分 时 日 月 周），但你写了6个星号，这会导致Laravel无法正确解析任务时间，任务自然不会触发。

正确的写法应该是：

// 用Laravel内置的daily方法（默认每天0点执行）
$schedule->command('alert:dailly')->daily();

// 或者用正确的5字段cron表达式
$schedule->command('alert:dailly')->cron('0 0 * * *');

另外，顺便确认你的命令名称是否正确：alert:dailly是不是拼写错误？正常应该是alert:daily，如果命令类里定义的是daily，那这里的拼写错误会导致找不到任务（你说每分钟能运行，可能命令名确实是dailly，但还是要核对下app/Console/Commands/AlertDailly.php里的$signature字段）。

2. 核对时区配置的一致性 #

共享主机的Cron默认使用服务器系统时区，而Laravel的调度器使用config/app.php里配置的timezone（比如'timezone' => 'Asia/Shanghai'）。如果两者时区不一致，就会出现时间匹配不上的问题：

比如服务器是UTC时区，而Laravel是东8区，那服务器Cron在0 0 * * *（UTC时间0点）运行时，Laravel的本地时间是8点，而daily()默认是Laravel时间的0点执行，这时候任务不会触发。

解决办法：

• 要么把Laravel的时区改成和服务器一致（可以通过php artisan tinker执行date('T')查看服务器时区）；
• 要么调整服务器Cron的时间，匹配Laravel时区的0点。比如Laravel是东8区，服务器是UTC，那服务器Cron应该设为0 16 * * *（UTC16点对应东8区0点）。

3. 确保Cron命令使用正确的PHP路径和环境 #

共享主机的Cron执行环境和你登录SSH后的命令行环境不一样：

• Cron的PATH变量通常更窄，直接用php可能调用的是CGI版本，而不是CLI版本；
• 有些主机需要指定完整的PHP路径（比如/usr/local/bin/php或/opt/cpanel/ea-php81/root/usr/bin/php）。

你可以先在SSH里执行which php获取正确的CLI路径，然后把Cron命令改成：

/usr/local/bin/php -d register_argc_argv=On /home/path/domain.com/artisan schedule:run >> /home/path/domain.com/storage/logs/cron_schedule.log 2>&1

注意把/usr/local/bin/php换成你实际的PHP路径，同时把输出重定向到日志文件，这样可以查看执行时的错误信息（之前的> /dev/null会丢弃所有输出，没法排查问题）。

4. 查看日志找具体错误 #

不管是Laravel的日志还是Cron的输出日志，都是排查问题的关键：

• Laravel日志在storage/logs/laravel.log，可以搜索alert:dailly相关的条目，看有没有执行记录或错误；
• 上面修改后的Cron日志cron_schedule.log会记录schedule:run的执行情况，比如有没有检测到要执行的任务，有没有报错（比如依赖缺失、权限不足）。

5. 检查共享主机的Cron限制 #

有些共享主机会对Cron任务做限制：

• 比如禁止长时间运行的任务，如果你的alert:dailly命令执行时间过长，可能被主机杀死；
• 或者Cron的执行间隔有最低限制，不过每日一次通常是允许的；
• 还有的主机需要在cPanel的Cron设置里启用某些权限，或者验证任务的路径是否正确。

最后验证小技巧 #

你可以先把服务器Cron改成比如*/5 * * * *（每5分钟执行一次），同时把Laravel任务改成->dailyAt('10:00')（假设现在是接近10点），测试是否能在指定时间触发，这样可以快速验证时区和调度逻辑是否正确。

内容的提问来源于stack exchange，提问作者Luiz Wynne