composer install --dry-run 仅校验 composer.lock 在当前环境的可行性，严格复现真实 install 的全部平台检查、包可访问性及哈希验证流程，失败时精准定位根本原因。
composer install --dry-run 不会安装任何包，它只做一件事：校验当前 composer.lock 文件是否能在当前环境“走通”。不是预览要装什么，而是提前暴露“装不了”的根本原因。
为什么 composer install --dry-run 和 composer update --dry-run 完全不是一回事
前者是“验证锁文件可行性”，后者是“模拟更新决策”。install --dry-run 会严格复现真实 install 的全部校验流程，包括：
- 检查 PHP 版本、扩展（如
ext-mbstring）是否满足composer.lock中每个包声明的platform要求 - 确认所有包的 dist ZIP URL 是否可访问（尤其私有源或已下架版本）
- 验证
composer.lock的 SHA256 哈希与实际包内容是否匹配（哪怕只是本地缓存里的） - 检查
allow-plugins配置是否允许 lock 文件中记录的插件激活
它不输出“将安装 X 包”，而是在失败时直接告诉你卡在哪一步——比如 Package foo/bar has a PHP requirement incompatible with your PHP version (8.0.30)，这比等 install 执行到一半再崩更早、更准。
composer install --dry-run 必须搭配的参数组合
单独用 --dry-run 往往掩盖真实问题。生产部署前务必加：
-
--no-dev：跳过 require-dev，避免因测试工具链缺失导致误报 -
--ignore-platform-reqs=false：显式关闭平台忽略（注意是=false，不是不写）。否则默认为true，会绕过 PHP/扩展检查，失去校验意义 -
-v或--verbose：看到具体哪个包触发了平台不兼容或网络超时
典型命令：composer install --dry-run --no-dev --ignore-platform-reqs=false -v
CI/CD 流水线里怎么用才不翻车
在 GitHub Actions、GitLab CI 等环境中，install --dry-run 是上线前最后一道静态校验防线，但容易被以下情况骗过：
- 缓存目录（
cache-dir）路径落在 NFS 或 WSL2 挂载卷上：校验时能读缓存，真实 install 时 I/O 卡死，--dry-run不模拟解压和写入 - 配置了镜像源但未全局生效：比如用
composer config repo.packagist写错字段名（repos.packagist多了个s），--dry-run仍走官方源，结果真实 install 时超时 -
composer.lock里含私有包，但 CI 环境没配置对应认证（如auth.json）：--dry-run可能只报 401，不说明是认证缺失还是 URL 错误
建议在 CI 中先跑 composer config --global repo.packagist 和 composer config --global cache-dir 确认配置落地，再执行 --dry-run。
真正关键的不是“有没有报错”，而是报错信息是否指向你可控的环节——比如 PHP 版本不匹配可以改 runner；私有源不可达得查凭证；而“找不到包”大概率是 lock 文件本身已失效，该删 lock 重 update 了。
