Composer如何检查过期包 Composer依赖生命周期管理策略

Composer依赖管理：那些可能让你栽跟头的细节

在PHP项目里，依赖管理是绕不开的一环。`composer outdated` 这个命令，可以说是日常检查依赖状态的标配工具。但不少开发者会发现，有时候跑完命令，终端一片空白，心里就开始犯嘀咕：难道我的依赖全是最新的？其实，这里面有几个容易被忽略的细节。

composer outdated 为什么显示不了过期包？

先得说清楚，`composer outdated` 默认只关心你直接在 `composer.json` 里写下的那些依赖——也就是所谓的“主依赖”。至于它们拉进来的子依赖，比如 `lara vel/framework` 依赖的 `monolog/monolog`，命令是不会主动去扫的。所以，当你发现没有输出，一个很常见的原因是：所有直接依赖确实都满足版本约束，且没有可用更新。但深层依赖可能早就落后了好几个版本，只是你没看到。

那么，怎么才能把全景看清楚？

• 加个 `--all` 参数：`composer outdated --all`，这时候所有级别的依赖都会列出来，信息量会大很多。
• 如果只想快速确认自己该不该升级 Lara vel、Symfony 这类主框架，不加参数或者加 `--direct` 就够了。
• 版本跳得太猛？用 `--minor-only` 或 `--patch-only` 能帮你过滤掉那些破坏性的大版本更新，只看小版本或补丁变动，心里更有谱。
• 别忘了 PHP 版本约束。如果项目锁定了 `"php": "^8.1"`，有些新包可能因为平台不兼容而被跳过。这时候可以用 `composer show -p` 来检查一下平台配置。

如何判断一个过期包能不能安全升级？

不是所有标红的包都值得立刻动手。升级之前，可以先问自己三个问题：这个包在我的代码里被直接调用了吗？它有没有已知的安全漏洞？它的上游是不是已经停止维护了？举个例子，`symfony/polyfill-php81` 过期了，但如果你的 PHP 版本还是 8.1，那它其实只是一个“功能冗余”，算不上风险点。

实际操作中，可以这样判断：

• 先查 CVE。去 symfony security 或 GitHub Security Advisories 搜一下包名加“advisory”，看看有没有安全通告。
• 用 `composer show vendor/package` 看看它的 `type` 字段。如果是 `library` 或 `symfony-bundle`，通常需要关注；如果是 `metapackage`（比如 `lara vel/lara vel`）或者 `dev-dependency`，影响范围就比较有限。
• 运行 `composer depends vendor/package`，看看谁在用这个包。如果只有测试工具（比如 `phpunit/phpunit`）依赖它，那就可以缓一缓。
• 对 `dev` 分支或者 `@dev` 版本号要格外小心。`composer outdated` 不会提示这类不稳定版本是否“过期”，但它可能早就被弃用了。

composer update 的实际执行逻辑和陷阱

`composer update` 的行为比想象中要保守。它默认只更新 `composer.lock` 里的版本，不会强制升到最新。它尊重 `composer.json` 中的版本约束，比如 `"guzzlehttp/guzzle": "^7.2"`，所以有时候 `outdated` 显示有新版，但 `update` 却没反应。

这里有几个实操建议：

• 想升到约束范围内的最新版，可以指定包：`composer update vendor/package`，或者全量更新：`composer update`。
• 如果想让 Composer 忽略 `composer.lock`，强制重新计算依赖图，可以加 `--with-all-dependencies`。但这么做之前，务必先 `git commit`，否则很容易引入隐式冲突。
• 生产环境禁止直接 `composer update`。应该始终基于 `composer.lock` 部署，CI 流程里用 `composer install --no-dev --optimize-autoloader`。
• 注意 `minimum-stability` 设置。如果设为 `stable`，即使 `outdated` 显示有 `v2.5.0-rc1` 更高版本，也不会被纳入更新候选。

长期项目怎么避免依赖失控？

这个问题没有银弹，但有两个硬动作能显著降低维护成本。一是把 `composer outdated --direct --minor-only` 加进 CI 的每日定时任务，邮件通知负责人。二是对核心包（比如 `doctrine/orm`、`spatie/lara vel-permission`）单独建 `.github/dependabot.yml` 规则，让它只提 minor 补丁 PR，不碰 major 升级。

真正容易被忽略的，是间接依赖的生命周期。举个例子，你用的 `aws/aws-sdk-php` v3.200 依赖 `guzzlehttp/psr7` ^1.9，而后者早在 2023 年就 EOL 了。但只要你没直接 require 它，`outdated` 就不会提醒。这种链路，只能靠 `composer depends guzzlehttp/psr7` 主动去挖，或者用 `composer show --tree` 手动翻三层依赖树。