composer如何查看已过时的过期依赖_outdated命令结果分析【技巧】

composer outdated 默认仅检查直接依赖，需加 –all 才显示全部依赖；颜色和符号提示升级风险，! 标记表示含 BC 中断，–format=json 便于自动化解析，但安全漏洞须用 composer audit 检测。

composer outdated 命令默认只显示直接依赖的过期版本

执行 composer outdated 时，它默认只检查你 composer.json 中直接声明的包（即 require 和 require-dev 下的顶层依赖），不会递归扫描整个依赖树里的所有间接依赖。这意味着很多实际已过时的子依赖（比如 monolog/monolog 被 symfony/console 拉入）根本不会出现在结果里——除非你显式加参数。

常见误判场景：看到输出“无过期包”，就以为项目完全干净，其实深层依赖可能早已落后两三个大版本。

• 用 composer outdated --all 才会列出所有依赖（含 transitive）及其当前/最新可用版本
• 加 --direct 可强制只看直接依赖（等价于不加参数，但语义更明确）
• --minor-only 或 --patch-only 可过滤更新类型，避免被次要/补丁级更新刷屏

颜色和符号含义决定是否真该升级

默认输出中，不同颜色和前缀传递关键信号：yellow 表示有新版本但未超出当前约束（如 "^2.8" 允许升到 2.9.0）；red 表示有版本满足你的 version constraint 但尚未安装（通常是 composer update 没跑）；而 green 或无色则多为已锁定或无更新。

特别注意带 ! 标记的行（如 doctrine/dbal 3.6.4 → 3.7.0 !），这表示新版本含 BC-breaking 更改，composer 已识别其 conflict 或 replaces 字段，但没阻止显示——升级前必须查其 CHANGELOG。

• 红色箭头（→）右侧版本若高于 composer.lock 中记录的版本，说明 composer install 后未及时 update
• 版本号后带 (stable) / (RC) / (dev) 提示稳定性差异，require 中未设 "minimum-stability" 时，RC 版本不会被纳入推荐
• 某些包显示 not in require，代表它是间接依赖且未被任何直接依赖的 require 显式声明，这类包升级风险更高——得先确认哪个父包在用它

结合 –format=json 精准提取过期信息做自动化检查

人工扫终端输出容易漏，CI 或脚本中建议用 JSON 格式解析，再按需过滤。例如检测是否存在 major 级过期（即主版本跃迁），可快速定位高风险项：

composer outdated --direct --format=json | jq -r '.packages[] | select(.latest.major > .installed.major) | "(.name) (.installed.version) → (.latest.version)"'

注意：--format=json 默认仍只输出直接依赖；加 --all 才能拿到完整树，但 JSON 结构会变深（含 required_by 字段），解析时需多一层遍历。

• JSON 输出中 .warning 字段非空，通常意味着该包已标记为 abandoned（如 "warning": "Package guzzlehttp/ringphp is abandoned, you should avoid using it. Use guzzlehttp/guzzle instead."）
• composer outdated --no-dev 在生产环境检查时务必加上，排除 require-dev 干扰
• 若某包始终显示过期但 composer update vendor/package 失败，大概率是 composer.json 中其他依赖的版本约束锁死了它，需用 composer depends vendor/package 追溯冲突源头

outdated 不等于安全漏洞，但往往是漏洞温床

composer outdated 完全不检查 CVE 或安全公告，它只比对 Packagist 上的最新稳定版 tag。一个包可能已过时 12 个月却无已知漏洞，也可能刚过期 3 天就曝出 RCE（如 laravel/framework 某些 8.x 补丁版）。别把 outdated 当安全报告用。

真正要查漏洞，必须用 composer audit（Composer 2.5+ 内置）或第三方工具如 security-checker（已归档）、roave/security-advisories（通过冲突机制阻断已知危险版本）。

• composer audit --format=github 输出可直接粘贴进 github PR 描述，方便团队聚焦修复
• 有些过期包（如 phpunit/phpunit）即使显示 10.5.0 → 10.5.2，也值得立即更新——因为测试框架的 patch 版常含关键 bug 修复，影响 CI 稳定性
• 长期忽略 outdated 的项目，往往在某次 composer update 时突然爆出大量冲突，根源就是中间缺失了多个兼容层过渡