composer outdated 显示的包版本与 composer.json 不一致，因为它比对的是 vendor 中已安装版本在 Packagist 上是否存在满足当前 require 约束的新稳定版，而非直接对照 composer.json 的版本约束；例如 "^2.8" 已装 2.8.1 但存在 2.9.0 会提示过期，而 3.0.0 因不满足约束则不显示。
composer outdated 显示的包版本为什么和 composer.json 不一致
因为 composer outdated 默认检查的是「已安装的依赖」在当前仓库（Packagist）上是否有更新，而不是比对 composer.json 中写的约束范围。它看的是 vendor/ 里实际装的版本，再查这些版本是否还有满足你当前 require 规则的新版可升。
- 比如
"monolog/monolog": "^2.8"，你装了2.8.1，但官方已发2.9.0—— 它会标为过期；但如果最新是3.0.0，而^2.8不允许升到3.x，那它就不会显示 - 如果某个包在
composer.json里用"dev-main"或"dev-develop"这类开发分支，outdated通常不报——它只查稳定标签（tag），不跟踪分支 HEAD - 私有仓库或 VCS 包若没配置
repositories或镜像同步延迟，也可能漏判
怎么让 outdated 只看直接依赖（忽略子依赖）
加 --direct 参数，否则默认连所有传递依赖都扫一遍，输出几十页根本没法盯重点。
-
composer outdated --direct：只列出你在composer.json的require和require-dev里手动写的包 - 搭配
--minor-only可进一步过滤：只显示同主版本内的小版本更新（比如2.8 → 2.9），跳过2.x → 3.x这种可能破兼容的 - 想导出成表格方便筛选？用
composer outdated --format=json，然后 pipe 给jq处理，比肉眼扫强得多
为什么有的包明明有新版却不显示在 outdated 结果里
常见原因就三个：锁文件干扰、版本约束太松、或者包本身被标记为“ignore”。
-
composer.lock里锁死了版本？运行composer update --dry-run看实际能升哪些——outdated有时会受 lock 文件缓存影响，尤其你刚删过vendor没重装时 - 约束写成
"*"或"dev-master"？这种没有明确上限的写法，outdated无法判断“有没有更新”，直接跳过 - 检查有没有在
composer.json的minimum-stability设成stable，但你想升的版本是RC或beta——它默认不认非稳定版，得加--all才显示
CI/CD 里自动检测过期依赖容易踩的坑
别直接用 composer outdated 做失败断言——它默认返回 0 即使有结果，只有遇到错误（如网络失败）才非 0。
- 真要卡 CI，得自己判断输出内容：
composer outdated --direct --minor-only | grep -q "^\w"，有匹配就说明存在可升级项，再按需 exit 1 - 注意 PHP 版本兼容性：某些新版本依赖要求 PHP 8.1+，但你的 CI 还跑在 7.4 上——
outdated不校验这个，升了直接炸 - 团队协作时，有人本地跑了
composer update但忘了提交composer.lock？CI 里outdated的结果会和本地不一致，必须确保 lock 文件始终提交
真正麻烦的从来不是命令会不会用，而是搞不清它到底在跟谁比、按什么规则算“过期”。多看两遍 composer outdated --help 里关于 --direct、--all、--format 的说明，比背参数有用。
