composer outdated 默认仅检查直接依赖，需加 --all 才显示间接依赖；颜色和 ! 标识更新风险等级，json 格式便于自动化处理，安全审计须单独运行 composer audit。
composer outdated 默认只看直接依赖，不是“所有包”
它默认只扫描 composer.json 中 require 和 require-dev 下显式写的包，像 monolog/monolog 这种被其他包带进来的间接依赖（比如通过 laravel/framework 引入的），压根不会出现在默认输出里——你根本看不到它们已过时。
- 加
--all才会显示全部已安装包，包括间接依赖和suggest里的可选包 - 加
--direct是冗余操作，因为这就是默认行为；但明确写出来能提醒自己“我只在盯主干依赖” - 不加任何参数却以为“全扫过了”，是线上项目长期漏掉安全更新的常见原因
颜色和 ! 比版本号更重要
终端里黄色行（如 symfony/console v5.4.32 → v5.4.37）表示补丁更新，大概率安全；红色行（v5.4.32 → v6.0.19）说明约束允许主版本跃迁，但很可能破坏兼容性；而带 ! 的行（doctrine/dbal 3.6.4 → 3.7.0 !）是 Composer 自动识别出的 BC-breaking 更改，哪怕只是次版本升级也得查 CHANGELOG。
-
dev-main或dev-develop版本不会标为 outdated，因为没稳定版号可比——它不是“没更新”，而是“没法比” - 看到
(RC)或(beta)后缀，说明最新版不稳定，默认不推荐，除非你主动设了"minimum-stability": "RC" - 别只盯着“→ 右边那个数字大”，重点看
latest-status字段（JSON 输出里有），值为major就得停手
想自动化或进 CI？必须用 --format=json
人眼扫终端容易漏，尤其当输出超过一屏。JSON 格式字段明确：name、installed、latest、latest-status、description，还能配合 jq 精准过滤。
- 查所有主版本可升级包：
composer outdated --all --format=json | jq -r '.packages[] | select(.latest_status == "major") | "\(.name) \(.installed.version) → \(.latest.version)"' - CI 中建议加
--minor-only配合 JSON，只报非破坏性更新，避免流水线被意外的大版本卡住 -
composer outdated不检测漏洞，安全风险得靠composer audit单独跑
看到过时≠马上 update，单包升级才是常态
直接 composer update 容易因依赖冲突失败，尤其当多个包同时过时时。更稳妥的是锁定目标，逐个推进。
- 先确认想升哪个：
composer outdated | grep "guzzlehttp/guzzle" - 再精确升级：
composer update guzzlehttp/guzzle（自动重算其子依赖） - 如果要连带更新它的依赖树，加
--with-dependencies，但务必先读该包的UPGRADE.md或 release note - 降级反而更危险：改
composer.json里版本号后composer update vendor/package，可能触发连锁冲突，不如先composer show vendor/package --all看历史版本再决策
composer.json 里，却天天在跑。定期 composer outdated --all + composer audit 才算真正摸清底细。 
