php定时任务失败主因是环境不一致：需用绝对路径调用php和脚本，重定向输出查错；crontab字段顺序为分时日月周，周为0–6；禁用sleep轮询，避免sudo crontab权限混淆，确认cli与web版php版本一致。
PHP 脚本在 crontab 里不执行，先检查这三件事
绝大多数 PHP 定时任务失败，不是 crontab 配置错，而是环境没对齐。crontab 运行时用的是系统最小化 shell 环境（通常是 /bin/sh），不加载你的用户 profile，PATH、PHP 路径、扩展、工作目录全和终端里不一样。
- 用绝对路径调用 PHP：别写
php script.php，查清楚实际路径——运行which php，然后用/usr/bin/php或/opt/homebrew/bin/php这类完整路径 - 脚本路径也必须绝对：crontab 不在你预期的项目目录下执行，
./app/queue.php会报 “No such file or directory”，得写成/var/www/myapp/app/queue.php - 重定向输出看错误：加上
> /tmp/cron.log 2>&1，否则 silent fail，连错在哪都不知道
crontab 行怎么写才不会漏掉分钟/小时字段
crontab 字段顺序固定为：分 时 日 月 周 命令，新手常把“每5分钟”写成 */5 * * * *（对），但误写成 * */5 * * *（这是每小时的第0分钟执行，不是每5小时）。
- 每5分钟跑一次 PHP 脚本：
*/5 * * * * /usr/bin/php /var/www/myapp/artisan schedule:run >> /dev/null 2>&1 - 每天凌晨2点清理日志：
0 2 * * * /usr/bin/php /var/www/myapp/clean_logs.php >> /var/log/clean.log 2>&1 - 注意：周字段是 0–6（0=周日），不是 1–7；有些系统（如 Debian）把 0 和 7 都当周日，但 Alpine Linux 只认 0
PHP 内部用 sleep() 模拟定时？别这么干
用 while(true) { do_work(); sleep(300); } 启一个长进程挂后台，看似省事，实则埋雷：进程可能被 OOM killer 杀掉、部署重启后不自动拉起、无法精确控制并发、日志混在一起难排查。
- 它绕过了 crontab 的调度可靠性机制，比如失败重试、锁防止重复执行、系统级资源隔离
- 如果真需要秒级精度（crontab 最小粒度是1分钟），改用
systemd timer或专门的队列工具（如 Laravel Horizon + Redis），而不是在 PHP 里硬轮询 - 临时调试可以这么跑，但上线配置必须回归 crontab 或 job scheduler
为什么加了 sudo crontab -e 还是没权限写文件
用 sudo crontab -e 编辑的是 root 用户的 crontab，它执行命令时拥有 root 权限，但 PHP 脚本里如果用 fopen('log.txt', 'a')，默认写入位置是 root 的家目录（/root/），而你的 Web 服务通常跑在 www-data 或 nginx 用户下，根本读不到那个 log。
- 要么在命令里显式指定完整路径：
/usr/bin/php /path/to/script.php >> /var/www/myapp/storage/logs/cron.log 2>&1 - 要么改用非 root 用户的 crontab：
crontab -e（不带 sudo），然后确保该用户对脚本和目标目录有读写权限 - 更稳妥的做法：所有路径都用绝对路径，所有日志都写到项目可写目录（如
storage/），避免权限猜谜
实际部署时最常被忽略的，是 PHP CLI 版本和 Web 版本不一致——php -v 在终端里看到 8.2，crontab 却调用了系统自带的 7.4，导致 match 表达式或 str_contains() 直接报错。务必在 cron 命令开头加一句 /usr/bin/php -v 输出到日志，确认版本对得上。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
