composer install 不支持 --dry-run，直接使用会报错“Unrecognized option”，因其行为由 composer.lock 严格决定，无需预演；真正支持该参数的是 composer update 和 composer require（2.2+），其中 update --dry-run -v 可完整预览依赖变更及锁文件差异。
composer install 不支持 --dry-run，直接加会报错；真正能用 --dry-run 的只有 composer update 和 composer require（Composer 2.2+ 稳定支持）。
为什么 composer install --dry-run 没反应甚至报错
它根本不是合法命令。Composer 官方从没给 install 加过 --dry-run 参数——旧版会提示 Unrecognized option: --dry-run，新版直接拒绝执行。原因很实际：install 的行为完全由 composer.lock 决定，只要锁文件存在且格式正确，结果就是确定的，没必要“预演”。
- 想验证锁文件是否可解析？直接跑
composer install --no-scripts --no-plugins更快，失败即说明 lock 有问题 - 想确认 PHP 版本或扩展是否满足？
composer install本身就会卡在这一步，--dry-run并不提前暴露这些运行时约束 - 误以为它能预览“将装哪些包”？那是
composer update --dry-run的事，不是install的职责
composer update --dry-run 到底输出什么
它模拟完整更新流程：解依赖、比对版本、生成新锁文件内容，但不写入磁盘、不下载包、不执行脚本。关键输出在 verbose 模式下才可见：
- 开头的
Resolving dependencies块列出所有计划升级/降级/移除的包，例如：monolog/monolog: 2.10.0 → 3.5.0 - 结尾的
Writing lock file块显示新composer.lock的 diff（需加-v），能看出哈希、PHP 平台要求等变更 - 若当前
composer.lock已和composer.json一致，它就真的什么都不输出——不是 bug，是判断“无需更新”
常用组合：composer update --dry-run --no-install -v。其中 --no-install 是关键，防止某些旧版本忽略 --dry-run 并真去下载。
composer require --dry-run 的真实用途和坑
它唯一靠谱的用途是提前捕获“根本装不上”的硬性冲突：PHP 版本不匹配、扩展缺失（如 ext-gd）、依赖环、私有包认证失败等。这些错误在真安装前就抛出，省得删 vendor 重试。
- 它不检查 autoload 冲突：比如两个包都声明
"psr-4": {"App\": "src/"}，--dry-run完全不报，直到composer dump-autoload或运行时Class not found - 它不校验
post-autoload-dump脚本能否执行，也不加载项目 autoloader，所以脚本里 new 自己的类会直接失败 - 参数顺序不能错：
composer require foo/bar --dry-run有效，composer require --dry-run foo/bar在旧版会被忽略
CI/CD 里用 --dry-run 判断是否要构建？小心误判
它只反映依赖图变化，不反映环境一致性。常见陷阱：
-
composer update --dry-run成功，不代表composer install就能过——可能 vendor 缓存被污染、本地 dist 包哈希不匹配、甚至composer.lock被手动改坏 -
--dry-run不读vendor/composer/installed.json，所以完全不知道当前已装的包和 lock 是否对得上 - dev 依赖变更（如测试工具升级）不会触发
update --dry-run输出，但它可能让phpunit命令失效
真正可靠的 CI 校验是清空 vendor 后跑一次完整 composer install --no-dev --prefer-dist，再比对退出码和 composer.lock 内容。预演只是第一道过滤，不是最终答案。
