composer install --dry-run 不会真正安装依赖，仅解析校验 composer.lock 与当前环境兼容性，退出码为0表示可顺利落地，非0则暴露平台、网络或锁文件问题。
composer install --dry-run 不会真正安装依赖
它只做解析和校验，不写 vendor、不改 lock 文件、不触发 scripts。这点和 composer update --dry-run 类似，但行为边界更窄：install 本身就不该改 composer.json 或求解新版本，所以 --dry-run 主要用来确认当前 composer.lock 能否在当前环境顺利落地。
常见误判是以为它能“预览将装什么包”——其实不会列出具体包名，只报错或静默成功。真正要看装哪些包，得靠 composer install --no-install --dry-run（见下一条）。
- 退出码为 0 表示 lock 文件与当前平台兼容，所有包可下载、签名可验、PHP 扩展满足
- 退出码非 0 时，错误里出现
Could not fetch说明镜像连通性或权限问题；ext-xxx missing是 platform 检查失败；invalid lock file往往是 lock 文件损坏或被手动编辑过 - 它仍会读取
composer.json中的config段（比如cache-dir、fxp-asset-plugin配置），所以配置错误也会在这里暴露
想看具体会装哪些包？用 --no-install 而不是 --dry-run
composer install --dry-run 本身不输出包列表，这是设计使然。真要预览安装动作，得组合 --no-install：
composer install --no-install --ignore-platform-reqs
这个命令会解析 lock、计算需下载的 dist 包、打印完整清单（含 URL 和 size），但跳过实际下载和解压。注意：--ignore-platform-reqs 会让它忽略 PHP 版本和扩展检查，适合快速验证网络链路；生产环境建议去掉这个参数，否则可能掩盖真实兼容性问题。
-
--no-install会触发 autoloader 生成逻辑（除非加--no-autoloader），所以能看到 autoload 相关警告 - 若项目用了
platform配置（如"php": "8.1.0"），不加--ignore-platform-reqs时，它会严格比对当前 PHP 版本，失败就直接退出 - 某些插件（如
fxp/composer-asset-plugin）在--no-install下仍会尝试拉取 asset，可能卡住或报 403 —— 这时候得检查 User-Agent 是否被镜像拦截
CI/CD 中用 --dry-run 做部署前守门人
在 GitLab CI 或 GitHub Actions 里，composer install --dry-run 是低成本验证环节：它快（通常 1–3 秒）、不污染工作区、能提前捕获 lock 文件与目标环境不匹配的问题。
典型用法是放在部署流水线最前端，配合环境变量做平台约束检查：
COMPOSER_HOME=/tmp/composer-test composer install --dry-run --no-dev
这里 COMPOSER_HOME 隔离配置，--no-dev 缩小校验范围，避免因 dev-only 包缺失导致误报。
- 别在 Docker 构建阶段用它替代真实 install ——
--dry-run不生成 autoloader，也不解压任何文件，不能代替最终验证 - 如果 CI 报
SSL certificate problem，优先检查基础镜像是否自带过期 CA 证书（尤其 Alpine 小镜像），而不是立刻切镜像源 - 某些私有仓库要求 OAuth token，
--dry-run同样会走认证流程，token 过期或权限不足会直接失败
容易被忽略的副作用：pre-install-cmd 仍会执行
即使加了 --dry-run，只要 composer.json 里定义了 pre-install-cmd 脚本，它依然会运行。这不是 bug，是 Composer 的明确行为：脚本执行属于“安装前准备”，不在“dry”范畴内。
比如你写了清理缓存或生成配置的 pre-install-cmd，它会在 dry-run 时照常执行 —— 可能删掉不该删的文件，或写入临时配置干扰后续步骤。
- 安全做法是让这些脚本自行判断是否处于 dry-run 环境：检查
$_SERVER['argv']是否含--dry-run，或读取getenv('COMPOSER_NO_INTERACTION')辅助判断 - 更稳妥的是把清理类操作移到
post-root-package-install或独立 Makefile 里，避开 install 生命周期 - 如果你用的是 Laravel Mix 或其他前端工具链集成的脚本，它们往往没做 dry-run 兼容，得手动加 guard
真正麻烦的从来不是参数本身，而是它不声不响绕过你的预期——比如你以为加了 --dry-run 就万事大吉，结果 pre-install-cmd 把数据库连接池清空了，或者某个脚本偷偷改了 .env。动手前先扫一眼 scripts 段，比什么都管用。
