composer install --dry-run 的真实作用是校验 composer.lock 是否与 vendor/ 一致，仅模拟依赖解析、版本锁定检查等操作而不写入磁盘；若 lock 存在且匹配则提示“nothing to install”，否则列出将变更的包。
什么是 composer install --dry-run 的真实作用？
它不会真正下载、解压或写入任何文件，但会完整执行依赖解析、版本锁定检查、脚本钩子模拟（如 post-install-cmd）和权限验证。关键在于：它仍会读取 composer.lock，并按其精确还原环境——不是“预估要装什么”，而是“如果现在运行 install，会严格按 lock 文件做哪些事（但跳过磁盘操作）”。
--dry-run 和 composer update --dry-run 的行为差异
二者常被混淆，但逻辑完全不同：
-
composer install --dry-run：只校验composer.lock是否与vendor/一致；若 lock 存在且完整，通常输出Nothing to install, update or remove；若 vendor 缺失或不匹配，则列出将要安装/删除的包（但不执行） -
composer update --dry-run：会重新解析composer.json，计算最新兼容版本，对比当前 lock，列出所有将被升级/降级/新增/移除的包（即使 lock 是最新的） - 误用
install --dry-run想看“更新后效果”是无效的——它根本不会触发版本重算
实际使用时必须注意的三个陷阱
这个参数表面安全，但容易因环境或配置产生误导：
- 它默认启用
--no-scripts，所以即使 lock 文件里声明了post-install-cmd，也不会在 dry-run 中打印模拟日志；加--verbose也看不到脚本执行计划 - 如果项目启用了
platform-check（PHP 扩展或版本约束），--dry-run仍会失败并报错，例如：Your requirements could not be resolved to an installable set of packages.—— 这说明环境本身就不满足 lock 文件要求 - 它不检测
vendor/autoload.php是否可被 require；哪怕 dry-run 成功，后续手动 install 后仍可能因 autoloader 生成失败导致 PHP Fatal error
推荐组合命令：快速确认变更影响
单靠 --dry-run 不足以覆盖多数协作场景。更实用的做法是：
- 想确认「当前 lock 是否能干净还原」：运行
composer install --dry-run --no-progress - 想预览「升级依赖后的影响」：必须用
composer update --dry-run --with-dependencies，再配合git diff composer.lock - CI 流程中验证 lock 文件完整性：用
composer install --dry-run --no-interaction --no-progress 2>/dev/null || echo "lock file is broken"
最常被忽略的一点：dry-run 不校验 vendor 目录下已存在但未被 lock 记录的“幽灵包”——这些包不会出现在输出中，却可能在真实 install 后被意外删除。
