作曲家如何实现依赖更新自动提示与推送？

本文共计909个文字，预计阅读时间需要4分钟。

markdown使用`composer outdated`命令是最直接的检查方式，它会列出所有已安装但存在新版本的依赖包。默认情况下，它只会显示主版本号的变化（例如，从`symfony/console`的`5.4.32`到`6.4.0`）。但请注意，它不会自动判断版本是否兼容，只会比较`composer.lock`和Packagist上的最新稳定版。

常见误区是以为「有输出就该升级」，其实要结合 require 约束看：如果 composer.json 写的是 "monolog/monolog": "^2.0"，而 outdated 显示 3.0.0，那这个版本根本不会被 composer update 拉下来，因为不满足语义化约束。

• 加 --direct 只看 composer.json 显式声明的包，跳过递归依赖
• 加 --minor-only 或 --patch-only 可过滤更新粒度（需 Composer 2.5+）
• 加 --format=json 输出结构化数据，适合脚本解析

用 composer update --dry-run 预演真实更新效果

composer update --dry-run 不改任何文件，但会完整走一遍依赖解析流程，告诉你最终会装哪些版本、有没有冲突、会不会删包。这比 outdated 更接近真实场景，尤其适合 CI 中做更新可行性验证。

注意几个关键点：

• 它受当前 composer.json 的 require 和 require-dev 共同影响，dev 包也会参与解析
• 如果提示 Root package requires ... but it is not present，通常是本地 vendor 损坏或 lock 文件未提交
• 加 -v 可看到详细版本决策树，比如为什么某个包没升到最新——常因某间接依赖锁死了低版本

自动化检测：GitHub Actions + cron 定期跑 outdated

想让团队收到更新提醒，最轻量的做法是在 GitHub Actions 中用 cron 触发定时任务，执行 composer outdated --direct --minor-only 并把结果发 Slack 或邮件。重点不是「自动升级」，而是「自动发现可安全升级项」。

示例要点：

• 用 if: ${{ github.event_name == 'schedule' }} 避免 PR 时重复触发
• 加 --no-ansi --no-interaction 确保纯文本输出，方便 grep 过滤
• 若输出非空，说明有可更新包，这时再用 composer update --dry-run 验证是否真能升，避免误报
• 别在生产环境机器上跑 cron；应走独立 CI job，且使用与项目一致的 PHP + Composer 版本

为什么不用 composer self-update 做依赖更新提醒

composer self-update 只更新 Composer 自身二进制，和项目依赖完全无关。有人混淆是因为命令名带「update」，但它对 vendor、composer.json、composer.lock 零影响。

真正容易被忽略的点是：Composer 的依赖解析逻辑本身会随版本升级变化。比如 Composer 2.2 改了冲突处理策略，某些在 2.1 下能 update 成功的组合，在 2.2 下可能报错。所以定期更新 Composer 本身，有时反而会让 outdated 和 update 行为更不可预测——除非你明确需要新版特性，否则别把它纳入自动化更新流。