如何在Composer中查看过时的依赖包列表

如何在Composer中查看过时依赖包列表

先明确一个核心事实：composer outdated 默认只显示直接依赖，而非“所有过时包”。这意味着，你看到的列表里根本不会出现像 monolog/monolog 这类被 lara vel/framework 带进来的间接依赖，哪怕它已经停更三年。这个默认行为，是很多开发者误判项目依赖健康状况的根源。

为什么 composer outdated 没列出你预期的包

原因很简单：这个命令默认只扫描 composer.json 中 require 和 require-dev 下显式声明的包。至于那些被这些包“拖家带口”带进来的间接依赖，默认是完全不参与比对的。这就导致了几个典型的误判场景：

• 运行 composer outdated 后一片空白，但用 composer show monolog/monolog 一查，发现安装的是 v2.8.0，而 Packagist 上最新稳定版早已是 v3.5.0。问题就在于，monolog/monolog 是通过其他包引入的，不在你的直接 require 列表里。
• 看到某包显示 dev-main → dev-main，别急着下结论。这通常不是“没更新”，而是因为它压根没有稳定的版本号可供比对，outdated 命令自然无法判断其是否过时。
• 如果你的私有仓库未在 repositories 中正确配置，那么对应的包压根就不会出现在输出结果中，直接“查无此包”。

怎么真正看到全部过时包（含间接依赖）

想一窥全貌，加上 --all 参数是唯一的办法。但随之而来的往往是信息过载和大量“噪音”，因此必须配合其他参数进行精准过滤：

• 聚焦次要更新： 使用 composer outdated --all --minor-only。这个组合能帮你只看次版本更新，有效避开主版本跃迁可能带来的破坏性变更风险。
• 排除开发依赖： 运行 composer outdated --all --no-dev。这能过滤掉 require-dev 下的包，让你把注意力完全集中在生产环境的运行时依赖上。
• 自动化提取高风险项： 对于追求效率的团队，可以尝试这条命令链：composer outdated --all --format=json | jq -r '.packages[] | select(.latest_status == "semver-major-update") | "\(.name) \(.installed.version) → \(.latest.version)"'。它利用 jq 直接提取所有标记为主版本升级的项，避免人工查看时漏掉那些标红的行。
• 别依赖终端颜色： 需要警惕的是，在 CI/CD 等无头环境中，ANSI 色彩常常会丢失。因此，--no-ansi --format=json 才是实现自动化检测唯一可靠的输出格式。

哪些“过时”其实不该动

版本号变大，绝不等于必须立刻升级。盲目跟进，有时反而会引入风险。关键要看清楚以下几点：

• 约束是否允许： 例如，约束为 "guzzlehttp/guzzle": "^7.0"，当前锁在 7.5.0，而最新版是 7.9.2。这种情况可以安全升级，因为补丁和次版本更新都在约束允许的范围内。
• 警惕破坏性变更： 如果同一行显示 7.5.0 → 8.0.0 !，那个 ! 叹号就是在明确警告：已识别到破坏性更改。这时，哪怕只是次版本升级，也必须先去查阅项目的 UPGRADE.md 说明。
• 环境是否兼容： 比如 phpunit/phpunit 显示可从 9.6.15 升到 10.5.20，但你的项目在 config.platform.php 中设置为 "8.1"。而 10.x 系列要求 PHP 8.2+，这意味着实际上并不可安装，升级建议是无效的。
• 安全漏洞是另一回事： 必须明确，composer outdated 只检查版本新旧，不检测安全漏洞。即使 doctrine/dbal 显示为“最新”，也可能存在已知的 CVE。排查安全风险，必须单独运行 composer audit 命令。

最后，还有一个最容易被忽略的要点：composer outdated 的输出结果，完全基于本地的 composer.lock 文件和缓存的元数据。如果你的项目很久没有运行 composer update --lock 来同步版本信息，或者没有用 composer clear-cache 清理过旧缓存，那么这个命令反馈的信息很可能已经滞后了。它根本不知道远程仓库早已发布了新版本。所以，别扫一眼输出就以为“大局在握”，正确的做法是：先同步元数据，再做出判断。