Composer本身不自动监控或发现更新，需依赖Dependabot等外部工具生成PR；outdated仅做本地快照比对，非持续监控方案，且受限于稳定性设置、私有仓库支持及输出结构化程度。
Composer 本身不监控版本，也不自动发现更新——它只响应你手动执行的命令。真要实现“自动发现依赖更新”，必须靠外部工具轮询 Packagist 并生成 PR，而不是指望 composer update 或配置文件自动生效。
为什么 composer outdated 不是监控方案
它只是本地快照比对：读取当前 composer.lock 和 Packagist 元数据，列出「此刻」符合约束的新版本。但它不持续运行、不发通知、不写 Git 提交、不触发 CI。
- 默认只查稳定版，
"minimum-stability": "stable"会过滤掉所有-beta/-rc版本，即使它们已修复关键漏洞 - 不感知私有仓库——如果用了自定义
repositories，outdated可能完全不返回结果 - 输出无结构化字段，
grep解析易断，不适合集成进告警系统 - 每次运行都要连 Packagist，频繁调用可能被限流（尤其在 CI 中未加缓存）
GitHub 上用 Dependabot 实现自动 PR
这是目前最轻量、免运维的方案，但配置极易出错。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
.github/dependabot.yml必须存在且路径准确，写成dependabot.yaml或放错目录都不生效 -
package-ecosystem: "composer"是唯一有效值，写php或packagist会被忽略 -
directory: "/"表示根目录下有composer.json；子目录项目（如packages/foo/composer.json）必须显式写directory: "/packages/foo" - Dependabot 从不修改
composer.lock，CI 流程里必须加composer update --lock --no-install才能同步锁文件，否则 PR 合并后composer install直接失败
Renovate 更灵活但配置项更多
适合需要精细控制升级策略的团队，比如跳过 major 升级、按包名分组、或对接私有 Packagist。
- 必须显式启用：
"enabledManagers": ["composer"]，否则 Renovate 完全忽略 PHP 生态 - 私有包需配
"registryUrls": ["https://your-private-packagist.com"]，否则解析失败静默跳过 - 想让 PR 自动包含
composer.lock更新，得设"updateLockFiles": true（默认为false） -
"rangeStrategy": "bump"才会保留^2.8这类写法；不设则默认replace，直接改成"2.9.0"，破坏语义化约束
自己搭轻量监控要绕开三个坑
用 composer outdated --direct --minor-only 配合 cron 虽简单，但生产环境容易失效。
- crontab 默认 shell 是
/bin/sh，而 Composer 依赖 bash 特性，必须写成bash -c "cd /path && composer outdated ..." - PHP CLI 版本和 Web 环境不一致时，
outdated可能漏报（比如本地 PHP 8.2，但 cron 调用的是系统自带的 PHP 7.4） - 不加
--no-ansi会导致输出含控制字符，邮件告警里显示乱码，grep -q "."判断失败 - 首次运行前最好先
composer update --dry-run一次，确认网络、认证、平台约束都通，否则监控永远“没输出”
真正难的不是生成 PR 或发邮件，而是确保每次升级都落在语义化版本边界内、不突破 PHP 或扩展要求、且 composer.lock 的变更可追溯——这些细节一旦漏掉，自动化的价值就归零了。
