composer 没有 composer check-updates 命令，应使用 composer outdated 查看可升级包，默认显示当前版本约束下可安全升级的依赖，加 –all 显示所有新版（含需改 composer.json 的），加 –direct 仅检查直接依赖，带 ! 标记表示存在安全漏洞；执行前务必用 –dry-run 模拟升级，确认变更内容与 BC 风险。
Composer 没有内置的 composer check-updates 命令，这个命令不存在 —— 运行它会报错 Command "check-updates" is not defined。
composer outdated 用来查看可升级的包
这是 Composer 官方提供的、最直接替代“检查更新”的命令。它列出所有已安装但有新版可用的依赖（包括语义化版本范围内和范围外的）。
- 默认只显示 当前
composer.json版本约束下可安全升级 的包（即满足^1.2.0这类约束的最新兼容版） - 加
--all参数会显示所有有新版的包，哪怕需要修改composer.json中的版本号（比如从^2.1升到^3.0） - 加
--direct只检查你直接声明在composer.json中的包，忽略依赖的依赖 - 输出中带
!标记的表示存在安全公告（CVE），应优先处理
composer outdated --all --directcomposer update 的行为与 –dry-run 关键作用
真正执行升级前，用 --dry-run 模拟升级过程，能清晰看到哪些包会被更新、是否涉及 major 版本跃迁、是否有冲突。
-
composer update --dry-run：模拟全局更新，不改composer.lock -
composer update vendor/package --dry-run：只模拟单个包升级 - 注意：如果
composer.json里写的是"monolog/monolog": "2.0.*"这种松散约束，--dry-run可能仍会升级到2.9.0；但如果是"2.0.0"锁死版本，则不会动 - 输出里出现
Downgrading或Upgrading后跟major字样，意味着 BC break 风险，不能无脑运行
第三方工具：composer-require-checker 和 dependabot 不是替代品
有人误以为 composer-require-checker 能查更新，其实它只检查代码中 use 或 new 的类是否在 require 中声明，和版本无关。而 Dependabot 是 gitHub/gitlab 的自动 PR 工具，它底层调用的仍是 composer outdated + 解析策略，不是本地命令。
- 若想自动化检测，推荐在 CI 中加一步：
composer outdated --direct --minor-only --no-dev（仅检查小版本更新，避免意外升 major） - 注意
--minor-only是 Composer 2.2+ 才支持的参数，旧版本不识别 - CI 中不要用
--all，否则每次都会因有大版本更新而失败，失去意义
常见错误：把 require-dev 包当成线上风险
很多开发者看到 phpunit/phpunit 可升级就立刻 update，但它是 require-dev，不影响生产环境运行时。是否升级取决于你的测试基础设施是否兼容新版本。
- 区分
--with-dependencies（默认开启）和--no-update-with-dependencies：后者只升指定包，不连带升级其子依赖，适合排查问题 - 升级前务必确认
composer.lock是否提交 —— 没锁文件的项目，不同人install出来的依赖可能完全不同 - 升级后至少跑一次
composer validate和composer dump-autoload -o，避免 autoloader 错乱
真正要警惕的不是“能不能升”，而是“升完会不会崩”。outdated 只告诉你“有新版”，--dry-run 才告诉你“升了会怎样”——这两步缺一不可，跳过任何一步都容易在线上触发未预期的异常。