composer outdated 默认无输出表示所有依赖均为最新兼容版本，并非命令失效；它仅列出满足 composer.json 约束且 Packagist 上存在新稳定版的已安装包。
composer outdated 默认不输出任何内容，不代表没用或失败——它只在真有可升级包时才打印，全最新时就是空屏。
为什么 composer outdated 什么都没显示？
这是最常被当成“命令失效”的误判场景。它默认行为是：仅列出当前 composer.lock 中已安装、且 Packagist 上存在「满足你 composer.json 版本约束」的新稳定版的包。如果全部锁死在最新兼容版本，就真的一行不输出。
- 先确认锁文件是否同步：运行
composer install或composer update --lock，避免composer.json改了但composer.lock滞后 - 想强制看全貌：加
--all参数，会列出所有已安装包（含无更新/不可升的），方便排查是否漏包 - CI 环境尤其要注意：很多流水线跳过
install直接跑outdated，结果永远为空——因为 vendor/ 和 lock 文件根本没生成
怎么只关注自己写的依赖，别被子依赖刷屏？
默认输出包含所有间接依赖（比如 symfony/console 被 laravel/framework 带进来），几十上百行里很难盯住你手动 require 的那十几个包。
- 加
--direct：只显示composer.json的require和require-dev下直接声明的包 - 加
--no-dev：排除开发依赖，进一步收窄范围（比如你不用本地调试工具，就别管phpunit/phpunit） - 组合使用更精准：
composer outdated --direct --no-dev --minor-only，只看主干依赖的次要版本更新
composer outdated 显示的“最新版”为什么和 Packagist 不一致？
它查的是你当前生效的仓库源，不是默认的 packagist.org。如果你配置过私有源、镜像（如阿里云）、或关过官方源，结果就只基于那个源的元数据。
- 查当前源：
composer config --list | grep repositories - 临时切回官方源验证：
composer config --global repo.packagist https://packagist.org，再跑outdated - 私有包更新后记得清缓存：
composer clear-cache，否则可能卡在旧版本列表里 - 注意镜像同步延迟：某些国内镜像更新慢几小时，
outdated可能漏掉刚发布的补丁版
别把 outdated 当升级依据，它不校验兼容性
它只做静态比对：「锁文件里版本」vs「源里最高匹配稳定版」。完全不解析依赖图、不检查 PHP 版本、不读 conflict 规则、也不管安全漏洞。
- 某包显示
2.10.0 → 3.5.0？先看composer.json里是不是写了^2.0——如果是，3.5.0根本不会被update安装 - 真正要升级前，必须跑：
composer update --dry-run vendor/package，它才会报出冲突、降级、平台不满足等真实问题 - 查安全风险？用
composer audit（Composer 2.5+ 内置），outdated输出里没有任何 CVE 或修复标识
最易被忽略的一点：outdated 对 dev-main、dev-develop 这类分支引用基本无效——它没法比对 commit 和 tag，只会标为 up to date 或跳过，但其实已有新 tag 发布。这类包得靠人工盯 CHANGELOG 或 git ls-remote 查。
