composer outdated 是唯一靠谱的入口，它基于 composer.lock 与 packagist 实时元数据比对，精准反映当前约束下可升级版本，支持 --direct、--all、--security-only 等参数适配不同场景，但需配合 update --dry-run 验证实际兼容性。
直接用 composer outdated，别信“check-updates”或拼错的 outpdated——这些命令不存在或已废弃。
为什么 composer outdated 是唯一靠谱的入口
它不是“能用”，而是唯一基于 composer.lock 与 Packagist 实时元数据比对的官方命令。结果反映的是“当前锁死版本在你 composer.json 约束下，到底还能不能升”，不是泛泛而谈“有新版本”。
- 默认只报
^2.0范围内可升到的最新2.x版（比如从2.3.5→2.10.0），不报3.0.0 - 加
--all才会显示“明明有3.0.0但被你的^2.0卡住”这类信息 - 输出带
!标记的行，表示该更新含已知 CVE 修复（需 Composer 2.2+） - 如果什么都没输出，大概率是版本写死了（如
"monolog/monolog": "2.8.0"）或用了dev-main分支
composer outdated 常见参数组合怎么选
不同场景要换参数，硬套默认行为容易漏重点或误报：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer outdated --direct --minor-only：只看你自己写的包、且只关心2.x → 2.y这类保守升级，CI 中最稳 -
composer outdated --all --format=json | jq 'map(select(.version != .latest))'：脚本化过滤出真有变化的包，跳过dev-main或锁定包 -
composer outdated --security-only：只揪出带已知漏洞的包（Composer 2.2+），上线前必跑 -
composer outdated --no-cache：CI 中防缓存导致元数据滞后，尤其在安全公告刚发布后
光看 outdated 不够，必须配 update --dry-run
outdated 是静态比对，update --dry-run 才是真实走一遍依赖解析。两者结果常不一致：
-
outdated显示symfony/console可升到6.4.0，但update symfony/console --dry-run报冲突？说明别的包（比如phpunit/phpunit）硬依赖symfony/console ^5.4 -
outdated没标红，但--dry-run显示Downgrading monolog/monolog from 2.10.0 to 2.9.0？那是因高版本和你当前 PHP 版本不兼容，outdated没做平台校验 - 想确认某次 CI 自动升级是否安全？必须把
composer update --dry-run当成前置检查，不能只靠outdated输出为空就放行
CI/CD 中自动化检查最容易翻车的三个点
不是命令不会用，而是环境和逻辑没对齐：
- 在 CI 中直接跑
composer outdated而不先composer install—— 锁文件可能还是旧的，结果不准 - 用
--all做门禁（exit code 非 0 就失败），结果每次都有主版本更新就永远过不了，失去意义 - 以为
outdated能替代composer audit查漏洞，漏掉无版本更新但存在 CVE 的老包（比如某包1.2.0有漏洞，1.2.1修复了，但你锁死在1.2.0，outdated不会提醒）
真正卡住自动更新的，往往不是命令本身，而是 composer.json 里那几行版本约束、PHP 平台配置、以及谁在依赖树里拖后腿——outdated 只负责暴露问题，解法得靠 depends、show -l 和 --dry-run 组合排查。
