php脚本被crontab调用时常见问题包括：环境差异致类/函数未找到、时区不一致、日志缺失、超时被杀、并发冲突等；需显式引入自动加载器、用绝对路径、校准时区、加日志、设资源限制、加文件锁或数据库互斥。
PHP 脚本被 crontab 调用时找不到函数或类
crontab 运行环境和 Web 环境完全不同：没有 $_SERVER、没加载自动加载器、include_path 也不一样。直接写 php /path/to/script.php 很可能报 Class not found 或 function undefined。
- 在脚本开头显式引入自动加载器，比如
require '/var/www/vendor/autoload.php'; - 用绝对路径包含依赖文件，避免相对路径失效（
__DIR__ . '/config.php'比include 'config.php'可靠） - 检查 PHP CLI 版本是否和 Web 一致：
crontab -e里写/usr/bin/php -v测试，别默认用php别名 - Web 环境下通过
.env加载的配置，在 CLI 下不会自动读取，得手动putenv("APP_ENV=production")或重载
crontab 时间表达式总不按预期执行
最常见原因是时间格式写错，或系统时区和 PHP 时区不一致。比如你设了 0 2 * * * 想每天凌晨 2 点跑，结果发现是 UTC 时间，而服务器本地是 CST，实际执行在凌晨 10 点。
- 确认系统时区：
timedatectl status；PHP 时区由date.timezone决定，CLI 和 FPM 可能不同，用php -r "echo date_default_timezone_get();"查 - crontab 不支持
*/5 * * * *这种写法里的秒级精度——它最小单位是分钟，别想用 cron 做秒级调度 - 测试时先用
* * * * *（每分钟）验证脚本能跑通，再逐步收紧时间表达式 - 日志必须加：在 crontab 行末尾加
> /var/log/mytask.log 2>&1，否则失败无声无息
PHP 脚本执行超时或被 kill 掉
CLI 默认没有超时限制，但系统层可能有资源限制（比如 memory_limit、max_execution_time），或 crontab 启动的 shell 会继承某些 ulimit 设置。
- 脚本开头强制设置：
set_time_limit(0); ini_set('memory_limit', '512M');，别依赖 php.ini - 避免在循环里不断
new大对象，记得unset($item)或用gc_collect_cycles()主动回收 - 如果任务涉及大量数据库操作，拆成小批次处理，比如每次查 100 条，处理完再
sleep(0.1)防止锁表或连接池耗尽 - 注意 crontab 的 PATH 很窄，
exec('curl')可能失败，改用绝对路径exec('/usr/bin/curl')或提前putenv('PATH=/usr/local/bin:/usr/bin:/bin')
多个定时任务并发冲突（比如同时写同一文件或更新同一条数据库记录）
crontab 不管你脚本有没有跑完，到点就起新进程。没做互斥控制的话，两个 php export.php 可能同时写 report.csv，结果文件损坏。
立即学习“PHP免费学习笔记（深入）”；
- 用文件锁最简单：
$fp = fopen('/tmp/export.lock', 'c'); if (!flock($fp, LOCK_EX | LOCK_NB)) { exit("locked\n"); } - 数据库层面加唯一任务标识 + 状态字段，启动前先
UPDATE tasks SET status='running' WHERE id=123 AND status='pending'，影响行为 1 才继续 - 避免用
file_exists() + touch()判断锁，存在竞态条件；必须用原子操作（flock或 DB UPDATE） - 锁文件记得在脚本退出前
flock($fp, LOCK_UN); fclose($fp);，但更要防异常退出——用register_shutdown_function()包一层更稳妥
真正麻烦的不是写一次脚本，而是让调度长期稳定：环境差异、权限变化、日志轮转、锁残留、PHP 升级后扩展缺失……这些细节不盯紧，过两个月准出问题。
