composer install --dry-run根本不存在，官方从未实现，运行必报“unrecognized option: --dry-run”错误；真正支持该参数的是composer update和composer require（2.2+稳定支持），因install行为由composer.lock严格决定，无需预演。
composer install --dry-run 根本不存在
直接告诉你：运行 composer install --dry-run 必然报错 Unrecognized option: --dry-run。这不是你配置不对，也不是版本太低——Composer 官方**从未实现**这个参数。所有声称它“存在”或“在 2.2+ 支持”的说法，都是混淆了 composer update 和 composer require 的行为。
原因很明确：install 命令的设计目标是“按 composer.lock 精确还原”，它不重算依赖、不响应 composer.json 的变更，也无需预演。官方认为它本身已是确定性操作，加 --dry-run 没有意义。
- 别再试
composer install --dry-run，它不会工作，也不该工作 - Stack Overflow 或旧博客里贴的示例，大概率是把 npm/yarn 的习惯错误迁移到 Composer
- 如果你看到某文档说“支持”，请检查它是否实际执行了
update或require命令却写错了命令名
想预览 install 行为？看 vendor 和 lock 是否一致
composer install 真实的“预览”方式，是让它自己说话：删掉 vendor/，再跑一次 install，观察输出和退出码。
当 vendor/ 与 composer.lock 完全匹配时，composer install 会直接输出 Nothing to install, update or remove；只要有一丁点不一致（比如少了一个包、版本哈希对不上），它就会明确列出将要安装/更新/删除的条目——这才是最真实、最可信的“模拟”结果。
- CI 中验证环境一致性，必须先
rm -rf vendor，再跑composer install --no-dev --prefer-dist --quiet --no-interaction - 检查退出码：非 0 表示
lock文件无法满足（平台不兼容、包已被移除等） - 不要依赖
--dry-run，它根本不读vendor/composer/installed.json，也校验不了 dist 包哈希
真正需要干运行时，用 update 或 require
如果你改了 composer.json（比如调了 PHP 版本、加了新包、放宽约束），想确认锁文件会怎么变、哪些包会被升级或降级，请用 composer update --dry-run。
它会完整重算依赖图，访问 Packagist 或私有源，输出 Updating、Downgrading、Installing 列表。加 -v 能看到为什么某个包被降级、哪个扩展缺失导致候选版本被排除。
-
composer update --dry-run monolog/monolog可聚焦单个包影响 -
composer require guzzlehttp/guzzle --dry-run适合开发阶段快速评估新增依赖的连锁反应 -
--with-dependencies必须显式加上，否则子依赖的降级不会显示 - 注意：它不校验
ext-gd是否真已启用，也不检查 autoload 冲突，这些要等真实install或dump-autoload才暴露
--dry-run 不是万能安全阀
它只解决“依赖图能不能算出来”，不保证“算出来的包跑得起来”。很多关键问题，--dry-run 默认完全不触碰：
-
require-dev中的扩展依赖（如phpunit/phpunit需ext-dom）默认不校验，除非加--with-dependencies - 私有仓库认证失败、镜像超时、token 过期等问题，往往在
--dry-run阶段不触发 - 两个包都注册了相同的 PSR-4 命名空间，这种 autoload 冲突要等
composer dump-autoload才报错 - PHP 版本要求写在
composer.json里，但--dry-run不检查当前 PHP 实际版本是否满足
最麻烦的不是命令敲错，而是扫完 --dry-run 输出没看到 Downgrading 就以为万事大吉——它只告诉你“能装”，不告诉你“装完能不能跑”。
