如何使用Composer检查过期的依赖包？（outdated命令详解）

能，composer outdated 默认只显示版本约束内可更新的包，不标安全或主版本变更；需加 –all 查主版本升级、–direct 限直接依赖、composer audit 查安全漏洞。

composer outdated 命令能直接列出过期包吗？

能，但默认只显示「有新版本可用」的包，且不区分是否为安全更新或主版本升级。它不会自动标出 security 或 major 变更，需要加参数才能看到关键信息。

执行 composer outdated 后，输出格式是：vendor/package、当前安装版本、最新稳定版本、是否允许更新（基于 composer.json 中的版本约束）。

• 如果某包当前是 ^2.1.0，而最新版是 2.5.3，它会显示为「可更新」
• 但如果最新版是 3.0.0，而你的约束是 ^2.1，它默认不显示——因为 Composer 认为这超出允许范围
• 想强制看所有更高主版本（包括 break change），得加 --all

如何让 outdated 显示安全更新和主版本变化？

用 --outdated 参数本身不包含安全标识，真正起作用的是两个组合：

• composer outdated --direct：只检查 composer.json 里直接声明的包，排除层层依赖的噪声
• composer outdated --all：无视版本约束，列出所有包的最新可用版本（含 v3.x 即使你锁在 ^2.0）
• 安全更新需配合 composer audit（Composer 2.5+ 内置），outdated 本身不检测漏洞

常见误操作：以为 outdated 能替代 audit。实际上，一个包可能版本旧但无已知漏洞；也可能版本新却存在未修复 CVE —— 这两者必须分开查。

为什么有时候 outdated 没输出，但实际有更新？

最常见原因是本地 lock 文件没更新，或缓存导致元数据滞后。Composer 的 outdated 基于 composer.lock 和远程仓库元数据比对，不是实时爬包源。

• 运行前先确保 lock 文件是最新的：composer update --lock（不改依赖，只刷新 lock）
• 清除过期缓存：composer clear-cache
• 某些私有仓库未配置 repositories，会导致对应包完全不出现在 outdated 列表中
• 若项目用了 platform-check 或 config.platform，php 版本模拟可能影响兼容性判断，导致“应显示却未显示”

用 –format=json 输出结构化结果方便脚本处理

CI/CD 流程中常需要解析过期包列表，--format=json 是唯一可靠方式。注意它输出的是完整对象，不是简单数组。

{     "vendor/package": {         "name": "vendor/package",         "version": "1.2.3",         "latest": "1.4.0",         "latest-status": "semver-compatible-update",         "warning": ""     } }

latest-status 字段值可能是：semver-compatible-update（小版本）、semver-major-update（主版本）、not-installable（当前约束下无法安装）。

别直接用 grep 解析文本输出——字段对齐不固定，列顺序可能变；JSON 是唯一可信赖的机器消费格式。

真正容易被忽略的是：outdated 不校验 require-dev 是否拖慢构建或引入测试工具链风险。这类包往往长期滞留，直到某天 CI 报错才被发现。建议定期加 --dev 单独扫一遍。