Composer定时任务需通过系统cron调用PHP脚本实现，关键在于使用绝对路径调用composer、显式设置COMPOSER_HOME、在cron中配置PATH和HOME，并在脚本中切换工作目录、用绝对路径写日志、区分require与require-dev依赖。
Composer 定时任务不是靠“挂载”，而是靠系统级 cron 调用 PHP 执行
很多人搜“Composer定时任务挂载”，其实 Composer 本身不提供定时能力，也不支持“挂载脚本”这种说法。真正可行的路径是：写一个 PHP 脚本（比如 check-deps.php），用 composer install 或 composer outdated 做依赖巡检，再让系统 cron 定期调用它。
关键点在于环境一致性——cron 默认没有加载用户 shell 的 PATH 和 Composer 全局配置，直接写 composer outdated 很可能报 command not found。
- 用绝对路径调用
composer，例如/usr/local/bin/composer（可用which composer确认） - PHP 脚本里用
putenv('COMPOSER_HOME=/path/to/composer/home')显式指定配置目录，避免权限或缓存问题 - 在 cron 中显式设置
HOME和PATH，例如：* 3 * * * HOME=/home/deploy PATH=/usr/local/bin:/usr/bin:/bin /usr/bin/php /var/www/app/check-deps.php >> /var/log/composer-check.log 2>&1
巡检脚本要区分“本地依赖”和“生产依赖”，别误判 dev-only 包
自动巡检如果只跑 composer outdated，会把 phpunit、mockery 这类 require-dev 包也列出来，导致告警噪音大。实际生产环境只需要关注 require 下的包是否过期或有安全风险。
- 加
--direct参数只检查直接依赖：/usr/local/bin/composer outdated --direct --minor-only --no-ansi - 加
--format=json方便后续解析，过滤出latest>installed的项 - 用
composer audit（Composer 2.5+）替代第三方工具做基础安全扫描，它只检查require，且默认跳过require-dev - 若项目用了
config.platform，巡检前确保脚本中运行composer update --lock或先composer install --no-dev，否则版本比对基准可能错乱
cron 日志权限和输出重定向容易被忽略，导致“看似运行实则失败”
cron 执行用户通常不是你的登录用户，脚本里写的相对路径、日志文件写入、甚至 file_get_contents('composer.lock') 都可能因权限或工作目录不对而静默失败。
- 脚本开头强制切换工作目录：
chdir('/var/www/app') or die('chdir failed'); - 所有日志路径用绝对路径，并确认 cron 用户有写权限（比如
/var/log/composer-check.log属于deploy:adm） - 不要依赖
$_SERVER['PWD']或 shell 当前目录，cron 启动时工作目录通常是/root或/home/user - 加简单心跳标记：脚本开头写一行时间戳到日志，结尾写完成标识，方便判断是卡住还是根本没触发
复杂项目需跳过部分包巡检，用 composer show + 白名单更可控
有些包更新频繁但业务不敏感（如 symfony/polyfill-*），或者你主动锁死了某个次要版本（如 "monolog/monolog": "2.9.1"），这时全量 outdated 会产生干扰。
更稳妥的做法是：先用 composer show --locked --format=json 拿到当前 lock 文件里的全部包列表，再逐个查 composer show vendor/name --all 获取可用版本，最后按白名单逻辑过滤。虽然稍重，但能避开 outdated 的语义歧义（比如它不识别 ^ 和 ~ 的兼容范围差异）。
示例片段（PHP）：
$pkg = 'laravel/framework';<br>$result = json_decode(shell_exec("composer show $pkg --all --format=json 2>/dev/null"), true);<br>if (!empty($result[$pkg])) {<br> $versions = array_keys($result[$pkg]);<br> $latestStable = end(array_filter($versions, fn($v) => !str_contains($v, 'dev-') && !str_contains($v, '@')));<br>}
这个逻辑比单纯依赖 outdated 输出更贴近你 lock 文件的真实约束。
巡检不是越全越好，关键是让每次告警都指向你真该介入的问题。路径、权限、作用域这三关没理清，脚本写得再漂亮也只会在日志里安静地失败。
