composer outdated 默认仅检查 composer.json 中直接声明的依赖，不扫描间接依赖；需加 --all 才显示全部，但建议搭配 --minor-only 等缩小范围；颜色和符号标识升级风险，--format=json 适合自动化判断。
composer outdated 默认只看直接依赖，不是“所有包”
执行 composer outdated 时，它根本不会扫描 monolog/monolog 这类被 symfony/console 拉进来的子依赖——哪怕它们已过时三年。它只比对 composer.json 的 require 和 require-dev 区块里你亲手写上的包。
- 想确认某个间接依赖是否过时？必须加
--all，否则压根不显示 -
--all输出极长，含大量 dev 分支、alpha 版本，容易误判；建议搭配--minor-only或--patch-only缩小范围 - 如果某包显示为
dev-main → dev-main，说明它没稳定版可比，outdated的“过期”判断在此失效
颜色和符号不是装饰，是升级风险信号
终端里红、黄、绿不是为了好看：red 表示有满足你版本约束的新版但没装（比如 "^2.8" 允许升到 2.9.0 却仍卡在 2.8.5）；yellow 表示新版已跨主版本（如 3.6.4 → 4.0.0），大概率含 BC-breaking；带 ! 的行（如 doctrine/dbal 3.6.4 → 3.7.0 !）代表 composer 识别出 conflict 字段或重大变更，不能跳过 CHANGELOG 直接更新。
- 别只盯着箭头右边的版本号，重点看左边是否已锁定（
dev-master或1.2.x-dev会掩盖真实兼容性） - 用
composer outdated --format=json | jq -r '.packages[] | select(.latest.major > .installed.major)'可快速筛出主版本跃迁项 - 颜色在 CI 环境可能丢失，建议加
--no-ansi+--format=json做自动化判断
想查“所有直接依赖”的最新版（不管有没有更新可用）
composer outdated --direct 只列出「当前已安装且有更新」的包，它会把已是最新版的包完全过滤掉——这不是 bug，是设计逻辑。如果你要一张完整清单，对比每个直接依赖和 Packagist 上的最新稳定版，得绕开 outdated：
- 先用
composer show --direct --no-dev拿到所有 require 中的包名和已装版本 - 再用脚本调 Packagist API（如
curl -s "https://packagist.org/packages/monolog/monolog.json" | jq -r ".package.versions[0].version"）取最新稳定版 - 注意：Packagist 有请求限流，生产环境别轮询；临时排查可用，长期应结合
composer outdated --direct --minor-only分批验证
过期 ≠ 必须升级，更不等于能安全升级
一个包显示 2.1.0 → 2.2.0，不代表 composer update vendor/package 就能成功——PHP 版本不匹配、其他依赖锁死旧版、conflict 规则冲突都可能让更新失败。尤其当多个包同时过时时，盲目 composer update 容易触发依赖解析死锁。
- 永远先跑
composer update --dry-run vendor/package看是否真能解出方案 - 主版本升级前，务必查 CHANGELOG 和 UPGRADE.md，别信“向后兼容”的宣传话术
- CI 流程里建议加
composer outdated --security-only做强制检查，安全漏洞不等人，但功能更新可以等测试排期
真正麻烦的从来不是“怎么看到过期”，而是“看到之后敢不敢动、怎么动才不崩”。版本约束写得太宽（比如 "*" 或 "^1.0"）或太死（"1.2.3"），都会让 outdated 的结果失去指导意义。
