composer show --outdated 在 composer 2.2+ 中已彻底移除，执行报错“command not defined”，必须改用独立命令 composer outdated；它默认仅检查 require 中的运行时依赖，不包含 require-dev、插件或被 replace 的包，且结果基于 composer.lock 与 packagist 稳定版的静态比对。
composer show --outdated 命令在 Composer 2.2+ 中已失效，执行会报错：Command "show --outdated" is not defined。必须改用 composer outdated。
为什么 composer show --outdated 会报错
这是 Composer 2.x 的明确弃用行为，不是拼写或权限问题。旧版 Composer 1.x 支持该写法，但当前稳定版（≥2.2）已完全移除该命令路径。系统不再识别 show 子命令后接 --outdated 这种组合。
-
composer show outdated（无双横线）会被解析为「查找名为 outdated 的包」，显然不存在，报Package outdated not found -
composer show --outdated（带双横线）触发命令未定义错误，因为show不接受--outdated参数 - 正确入口只有一个：
composer outdated，它是独立子命令，不是show的选项
composer outdated 默认只查 require 包，dev 包和插件都不在范围内
它默认忽略 require-dev 下的包（如 phpunit/phpunit）、Composer 插件（如 hirak/prestissimo），以及被 replace 或 provide 掩盖的 polyfill 包。这不是遗漏，是设计取舍：聚焦运行时依赖健康度。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 加
--all才能强制检查所有已安装项，包括 dev 包、插件、甚至dev-main分支 - 加
--direct可收缩范围，只看composer.json里你亲手写的那几行（比如"laravel/framework": "^10.0"），跳过层层嵌套的子依赖干扰 - 加
--no-dev是冗余操作——默认就不查 dev，除非你显式加了--all
composer outdated 没输出 ≠ 没包可升，常见静默原因
它只报告「满足当前版本约束 + 有新稳定版」的包。没输出，大概率是约束太死、锁太紧，或稳定性策略卡住了新版本。
-
"monolog/monolog": "2.9.0"这种精确版本写法，连2.9.1都不会提示 -
"minimum-stability": "stable"（默认）下，v3.0.0-rc1或dev-main直接被过滤，需加--stability=rc或--all才可见 -
composer.lock滞后于composer.json（比如改了约束但没composer update），outdated仍按旧 lock 快照比对，结果失真 - 包被
replace（如symfony/polyfill-mbstring替代原生扩展），默认不参与检查，加--all才暴露
别只信 outdated 输出，composer update --dry-run 才是真实校验
outdated 是静态元数据比对，update --dry-run 是完整依赖图重解析。两者结论打架太常见。
-
outdated显示guzzlehttp/guzzle可从7.5.0升到7.8.0，但update --dry-run报conflict with guzzlehttp/psr7 ^1.0→ 实际升不了，得先动子依赖 -
outdated不告诉你哪些包会被降级或移除，--dry-run会清晰列出Downgrading ...和Removing ...行 -
--dry-run会暴露 PHP 版本、扩展缺失等运行时硬性要求，比如The requested PHP extension ext-xml is missing - CI 中务必加
--with-all-dependencies，否则只升顶层包，子依赖仍卡旧版，可能埋下 BC break 隐患
真正容易被忽略的是：即使 outdated 和 --dry-run 都通过，major 版本跃迁（如 ^2.0 → ^3.0）仍可能引入接口变更，必须人工核对 CHANGELOG 或跑全量测试。命令只能告诉你“能升”，不能替你判断“该不该升”。
