php 8.5尚未发布，实际多为8.3或开发版；crontab不执行主因是php解释器路径错误、环境变量缺失、时区配置冲突及pcntl_fork系统限制，需逐一排查shebang、path、php.ini加载路径和socket连接方式。
php8.5 脚本在 crontab 里不执行，先看 shebang 和解释器路径
PHP 8.5 尚未发布（截至 2024 年中，最新稳定版是 PHP 8.3），所以你实际用的很可能是 PHP 8.3 或自己编译的 8.5-dev 版本。crontab 不执行脚本，90% 是因为没指定对的 PHP 解释器路径，而不是版本问题本身。
常见错误现象：command not found、PHP Parse error（但手动运行正常）、脚本静默失败无日志。
- 别直接写
php script.php—— crontab 的 PATH 很窄，php命令大概率找不到 - 用
which php查真实路径，比如/usr/local/bin/php或/opt/homebrew/bin/php（macOS Homebrew） - 脚本头部加 shebang：第一行写
#!/usr/local/bin/php，然后 chmod +x，crontab 里就能直接写脚本路径 - 如果脚本依赖 Composer autoloader，确保
vendor/autoload.php路径在 cron 环境下也有效（相对路径容易崩，建议用__DIR__拼全路径）
crontab 中执行 PHP 脚本时环境变量丢失怎么办
手动运行 OK，cron 里连数据库都连不上？不是 PHP 版本问题，是 shell 环境差异。cron 默认只加载 minimal 环境，$PATH、$HOME、$USER 都和你登录终端不一样。
- 在 crontab 条目开头显式声明变量，例如：
PATH=/usr/local/bin:/usr/bin:/bin HOME=/var/www USER=www-data * * * * * /usr/local/bin/php /var/www/artisan schedule:run - 更稳妥的做法：用
env -i模拟干净环境调试，或把关键变量导出到脚本开头：putenv('PATH=/usr/local/bin:/usr/bin:/bin'); - 数据库连接失败常因
PDO::ATTR_UNIX_SOCKET或 MySQL socket 路径不对 —— cron 下localhost可能走 TCP 而非 socket，改用127.0.0.1或显式指定unix_socket=/var/run/mysqld/mysqld.sock
PHP 8.3+ 的 pcntl_fork() 在 cron 里为啥总失败
想在定时任务里并发跑几个子任务？别在 crontab 直接调用含 pcntl_fork() 的脚本 —— 大多数 Linux 发行版的 cron daemon（如 vixie-cron）默认禁止 fork，会直接返回 Operation not permitted。
立即学习“PHP免费学习笔记（深入）”；
- 这不是 PHP 版本限制，是系统级策略。检查
/etc/crontab或systemctl status cron确认用的是哪个 cron 实现 - 替代方案：用
nohup php worker.php &启后台进程，或改用消息队列（Redis List +blpop）做轻量级分发 - 如果真要 fork，得改 systemd service 配置（
TasksMax=infinity）并用systemd-run替代 cron，但这已超出「定时任务」原始需求
为什么 date_default_timezone_set() 在 cron 里没生效
脚本里写了 date_default_timezone_set('Asia/Shanghai')，但 cron 输出的时间还是 UTC？不是函数失效，是时区设置被环境覆盖了。
- PHP CLI 模式会读取
php.ini中的date.timezone，而 cron 环境可能加载了另一个php.ini（比如/etc/php/8.3/cli/php.inivs/etc/php/8.3/apache2/php.ini） - 用
php -i | grep 'Loaded Configuration File'和php -r "echo date_default_timezone_get();"分别在终端和 cron 日志里对比输出 - 最稳写法：在脚本开头强制覆盖，且加判断防止重复设置：
if (!date_default_timezone_get()) { date_default_timezone_set('Asia/Shanghai'); }
真正麻烦的从来不是写一行 cron，而是确认那个 php 命令到底指向哪、加载了哪个配置、当前工作目录在哪、有没有权限读写日志文件 —— 这些细节不打日志根本看不见。
