composer outdated 默认只显示直接依赖的过时包，不检查子依赖；加 –all 可查看全部，但结果不保证兼容性或安全性，需结合 –major-only、–security-only 等参数过滤，且受镜像源、缓存、composer 版本等环境因素影响。
composer outdated 为什么没显示所有过时包？
默认只显示「直接声明在 composer.json 中的依赖」及其可升级版本，不会递归检查子依赖（transitive dependencies）。这是设计使然，不是 bug。
- 想看全部过时包（包括间接依赖），加
--all参数：composer outdated --all - 如果某包被锁在
composer.lock里且满足当前约束（如"monolog/monolog": "^2.0"锁着 2.10.0，而 2.11.0 已发布），它仍会被列为可更新 —— 只要新版本匹配你的版本约束 - 注意：
outdated不检查安全公告，也不等同于composer update的实际行为；它只是静态分析composer.json+ packagist 元数据
如何过滤出真正需要关注的过时项？
默认输出容易淹没关键信息，尤其项目大时。用参数快速聚焦：
- 只看主版本不兼容升级（如 2.x → 3.x）：
composer outdated --major-only - 只看已存在安全通告的包：
composer outdated --security-only（需提前运行过composer audit或启用 security-advisories 插件） - 排除 dev 依赖（避免干扰）：
composer outdated --no-dev - 按稳定性排序（dev/stable/beta 等）：
composer outdated --format=json配合 jq 解析更可控，比如只取stable版本
为什么本地结果和 CI 上不一样？
常见原因不是命令本身问题，而是环境差异导致元数据不一致：
-
composer outdated默认查的是 packagist.org 的最新索引，但如果你配置了私有仓库或镜像源（如阿里云、华为云），而该镜像同步延迟，就会漏掉新版本 - 本地执行前没运行
composer update --dry-run或composer clear-cache，可能缓存了旧的包信息 - CI 使用的 Composer 版本太老（如 2.0.x），不支持
--security-only或--major-only等参数，会静默忽略或报错 - 某些包设置了
"minimum-stability": "beta"，但你本地config.stability-flags覆盖了它，导致可见范围不同
检测结果能直接用于自动升级吗？
不能直接当 composer update 的输入用。它只告诉你“有哪些可升”，不保证升完能通过测试或兼容现有代码。
-
composer outdated输出的版本号是「最高匹配版本」，但未必是最稳妥的 —— 比如跳过一个带 breaking change 的次版本（2.9.0 → 2.11.0 中间有 2.10.0 是兼容修复，2.11.0 却改了接口） - 建议搭配
composer show vendor/package查具体变更日志，或用composer depends vendor/package看谁在用它，再决定是否升级 - CI 中别用
outdated触发自动 update；更适合做告警：比如composer outdated --direct --minor-only | grep -q .判断是否有次要升级待处理
最常被忽略的一点：outdated 不感知你项目中实际调用的函数或类 —— 它只看 composer.json 和 packagist 数据。哪怕某个包升级后删掉了你正在用的 SomeHelper::doIt()，它也不会预警。