composer outdated --all 显示全部包状态，--major-only --direct 识别主版本升级风险，dev-* 约束和稳定性设置会导致包不显示，升级前需 --dry-run 验证并查阅变更日志。
composer outdated 是查看项目中哪些依赖包存在新版本的最直接方式，但它默认只显示有更新的包，且不区分主版本变更——这恰恰是升级中最容易引发兼容性问题的地方。
如何让 composer outdated 显示所有包（包括无更新的）
默认行为只列出有可用更新的包，但有时你想确认某个特定包是否真的“已最新”，或者排查为什么某包没出现在列表里。加 --all 参数即可强制显示全部：
composer outdated --all
这时每行末尾会标出状态：up to date 表示当前满足 composer.json 中的版本约束且无更新；latest 表示已是最新稳定版；semver-safe-update 表示可安全执行 composer update vendor/package（即仅补丁/次要版本）。
识别潜在破坏性更新（主版本升级）
主版本变更（如 v2.9.4 → v3.0.0）通常不被 composer outdated 默认标记为“可更新”，因为 Composer 尊重语义化版本约束（如 "monolog/monolog": "^2.0" 不会自动匹配 v3.x）。要主动发现这类跳变：
- 使用
--major-only查看哪些包已有更高主版本（即使当前约束不允许）：composer outdated --major-only
- 搭配
--direct限制只看根依赖（即你手动写在composer.json里的包），避免被大量传递依赖干扰：composer outdated --major-only --direct
- 注意：输出中带
(major)标记的行，意味着新版本跨越了主版本号，需人工评估 BC break。
为什么某些包从不显示在 outdated 结果中
常见原因不是命令失效，而是约束本身阻止了更新检测逻辑：
-
"dev-master"或"dev-main"这类开发分支约束：Composer 认为“始终最新”，不会提示更新 - 使用了
dev-前缀 + 提交哈希（如"dev-feature-branch#abc123"）：版本被锁定到具体提交，无“新版本”概念 - 包已废弃（abandoned）且未设置替代包：Composer 仍能安装，但
outdated不会主动警告（需额外加--format=json并检查abandoned字段） -
minimum-stability设为stable，而新版本是beta或rc：即使存在，也不会列入结果
实际升级前必须验证的两件事
composer outdated 只是侦察兵，真正升级前得确认环境是否扛得住：
- 运行
composer update --dry-run vendor/package看依赖图是否会意外拉入冲突版本或弃用包 - 检查该包的 CHANGELOG 或 GitHub Releases 页面，重点看
Breaking Changes小节——尤其当outdated标出(major)时 - CI 流程中不要仅靠
outdated判断是否需要升级；它不校验 PHP 版本兼容性，比如一个新版本可能要求 PHP 8.2+，而你的环境仍是 8.1
真正麻烦的从来不是“有没有新版本”，而是“这个新版本能不能在我这跑起来”。outdated 不会告诉你 autoload 错误、扩展缺失或配置键名变更——那些得靠测试和日志说话。
