composer outdated 显示符合 require 规则的可更新包，默认仅限安全允许升级的版本；加 --all、--direct、--minor-only 等参数可定制范围，搭配 composer show -l 和 composer update --dry-run 可深入排查兼容性问题。
composer outdated 显示所有可更新的包
直接运行 composer outdated 就能看到当前项目中哪些依赖有新版本，包括语义化版本范围内（如 ^2.5.0）和范围外的更新。它默认只显示「安全允许升级」的版本——也就是符合 composer.json 中 require 规则的版本。
常见错误现象：执行后没输出，或只看到几个包。这通常是因为你的 require 版本锁得太死（比如写成 "monolog/monolog": "2.8.0"），或者本地 composer.lock 比远程仓库旧，还没拉取最新元数据。
- 加
--all参数可强制显示所有包（含 dev 依赖），哪怕它们当前版本已是最新的 - 加
--direct只看顶层声明的包（即你手动写进composer.json的），忽略间接依赖 - 加
--minor-only或--patch-only限制只显示次要/补丁级更新，避免意外升级大版本 - 首次运行前建议先
composer update --dry-run看下是否真能升级，避免outdated显示“有新版”但实际因冲突无法安装
composer show -l 列出所有已安装包及其版本约束
composer show -l 是比 outdated 更底层的视角：它不判断“有没有新版”，而是原样打印每个包在 composer.json 中声明的版本规则（如 ^7.4）、当前安装的实际版本、以及该包本身支持的最低 PHP 版本等元信息。
使用场景：当你怀疑某个包“明明有 8.0 版本却没出现在 outdated 结果里”，就可以用这个命令确认——如果它的 require 规则是 "php": "^7.4"，而你本地是 PHP 8.1，那 Composer 就会跳过它，即使 8.0 版存在也不会提示。
- 输出里带
[dev-master]或[dev-main]的，说明这个包是从 Git 分支安装的，outdated默认不检查这类源 - 如果某包显示
no version set (parsed as 1.0.0)，大概率是本地路径仓库或未打 tag 的私有包，需要手动验证更新逻辑 - 搭配
grep快速筛选：composer show -l | grep "laravel/framework"
composer update --dry-run 检查真实升级可行性
composer outdated 是静态分析，composer update --dry-run 才是模拟真实升级过程。它会解析全部依赖图、检查版本兼容性、PHP 扩展要求、平台配置冲突，并告诉你哪一步卡住了。
容易踩的坑：很多人以为 outdated 显示 “symfony/console: 5.4.33 → 6.4.7” 就代表可以一键升级，结果跑 update 时失败——往往是因为其他包（比如 doctrine/dbal）还没适配 Symfony 6，Composer 被迫降级或放弃。
- 加
-v（verbose）能看到详细冲突原因，比如：Root composer.json requires symfony/console ^6.4, found symfony/console[...]后面跟着一堆不满足的包 - 想单独试一个包：用
composer update vendor/package --dry-run，避免全量分析干扰判断 - 注意
--dry-run仍会访问 packagist.org，若网络受限或启用了私有镜像，结果可能和生产环境不一致
自动监控：用 composer audit 或第三方服务抓安全更新
composer outdated 不管安全漏洞，只管版本号。真正要监控风险，得靠 composer audit（Composer 2.5+ 内置）或外部工具。
它读取 packagist.org 的安全告警数据库（Symfony Security Advisories、FriendsOfPHP/security-advisories），对比已安装包的版本，直接指出哪些存在已知 CVE。
- 基础用法：
composer audit；加--format=json方便 CI 解析 - 如果返回空，不代表绝对安全——有些漏洞未被收录，或包作者没提交到 advisory 数据库
- CI 中建议固定超时和重试：
timeout 60s composer audit || echo "audit timeout, skipping"，避免因网络波动阻塞流水线 - 企业级场景别只信
audit：它不扫描你自己的代码、不检查二进制依赖（如 vendor/bin/phpunit 里的嵌入式组件），得配合 SCA 工具补位
版本监控真正的复杂点不在命令怎么敲，而在理解「为什么这个包不能升」——可能是 PHP 主版本不兼容，可能是某条 require-dev 依赖锁死了主版本，也可能是 packagist 元数据延迟。盯住 composer show -l 和 --dry-run 的输出，比盲目追新重要得多。
