composer outdated 默认仅显示直接依赖，不包含间接依赖；加 --all 可显示全部包，--direct 或不加参数为默认行为，--minor-only 限次要版本更新，--format=json 输出结构化数据便于解析，需注意过滤 dev 分支并用 --dry-run 验证升级可行性。
composer outdated 命令默认只显示直接依赖
运行 composer outdated 时，默认只会列出你 composer.json 中直接声明的包（即 require 和 require-dev 下的包），不会显示它们所依赖的子依赖（transitive dependencies）。这容易让人误以为“没包过时”，其实深层依赖可能早已落后多个小版本甚至大版本。
常见错误现象：执行后输出空，或只看到一两个包，但项目实际运行中却遇到兼容性报错或安全扫描告警。
- 加
--all参数可显示所有已安装包（含间接依赖）：composer outdated --all - 加
--direct（或不加参数）仅显示直接依赖，这是默认行为 - 加
--minor-only只显示有新次要版本（如 2.1.0 → 2.2.0）的包，跳过补丁和主版本更新
用 --format=json 获取结构化数据便于脚本处理
当需要自动化检查、CI 集成或批量分析时，文本输出难以解析。此时应使用 JSON 格式输出，字段含义清晰，且能准确区分是否可安全升级。
示例命令：composer outdated --format=json --direct
{
"packages": [
{
"name": "monolog/monolog",
"version": "2.9.1",
"latest": "3.5.0",
"latest-status": "major",
"description": "Sends your logs to files, sockets, inboxes, databases and numerous web services"
}
]
}
注意："latest-status" 字段值可能是 major、minor 或 patch，对应语义化版本的主/次/修订级别，这对判断是否可自动升级至关重要。
过滤掉 dev-master 或分支别名等不稳定版本
如果某个包被锁定为 dev-main、dev-develop 或使用了 branch-alias，composer outdated 会标为 dev 状态，并显示 latest: dev-main，但这不代表有“新版本”，只是当前跟踪的是开发分支 —— 它本身没有稳定版号可比。
这类结果干扰判断，建议主动过滤：
- 加
--no-dev跳过require-dev中的包（减少噪音） - 用
grep -v 'dev-'或jq 'select(.packages[].name | contains("dev-") | not)'后处理 JSON - 避免在生产环境长期依赖
dev-分支；如确需，应在composer.json中用^或~锁定到具体稳定 tag
结合 --dry-run 和 update 验证升级可行性
composer outdated 只告诉你“有更新”，不保证能顺利升级。尤其当多个包同时过时时，直接 composer update 可能因依赖冲突失败。
推荐分步验证：
- 先用
composer outdated --direct --minor-only找出风险较低的次要版本更新 - 对单个包尝试预演：
composer update vendor/package --dry-run，看是否引发冲突 - 若需批量升级，优先加
--with-dependencies确保子依赖同步调整 - 注意 PHP 版本约束：某些新版包要求 PHP 8.1+，而
outdated不校验该条件，需人工核对composer.json中的config.platform.php或当前运行环境
真正麻烦的往往不是“哪个包旧”，而是“哪个旧包的升级会连带破坏其他三个包的行为”——这点只能靠 --dry-run 和测试覆盖来暴露。
