--dry-run 的真实作用是“只计算、不执行”，它完整解析依赖、检查版本与平台约束、触发插件钩子并模拟 autoloader 构建，但跳过所有磁盘写入操作。
不能真正“预加载”依赖，但可以用 composer install --dry-run 模拟安装过程，提前看到 Composer 会做什么——包括下载哪些包、解析哪些版本、生成哪些 autoloader 映射，而完全不改动 vendor 目录或 composer.lock。
什么是 --dry-run 的真实作用
--dry-run 不是预加载，而是“只计算、不执行”。它会完整走通 Composer 的依赖解析、版本锁定检查、插件钩子触发（如 autoload 生成逻辑），但跳过所有写磁盘操作：不下载 zip、不解压、不写 vendor/、不改 composer.lock、不生成 autoload_static.php。
- 适合 CI 环境做“安装可行性验证”，比如确认 lock 文件与当前 PHP 版本/平台约束兼容
- 能提前发现冲突（如 require 了两个互斥版本）、缺失平台扩展（如 ext-gd 被 require 但未启用）
- 输出里会列出“将安装”“将更新”“将跳过”的包，和真实 install 几乎一致
如何用 --dry-run 辅助 autoload 分析
虽然不生成真实 autoload 文件，但 Composer 会在 dry-run 过程中模拟 autoloader 构建逻辑。配合 -v（verbose）可看到 PSR-4/PSR-0 映射推导结果：
composer install --dry-run -v | grep "autoload"
这能帮你确认：某类是否被正确映射到 vendor 包路径，或自定义 autoload 规则是否生效——无需等 install 完再测 class not found。
替代“预加载”的实用组合方案
若目标是让某些类提前可用（比如测试环境快速启动），可结合以下方式：
- 用
composer dump-autoload --classmap-authoritative提前生成高效 classmap（需确保无动态 require） - 在本地开发中，先运行
composer install --no-scripts，再手动触发关键 autoload 更新 - CI 中用
composer install --dry-run && composer install --prefer-dist --no-progress，把验证和执行拆开，避免失败时污染环境
注意几个常见误区
--dry-run 不等于“安全模式”——它仍会读取 composer.json/composer.lock、触发插件的 pre-install-cmd 钩子（如果插件没判断 dry-run 状态，可能意外执行副作用）。
- 它不会跳过脚本钩子，除非插件自己适配了
$event->isDryRun() - 不解决 autoload 缓存问题：OPcache 或 APCu 仍需手动清理，dry-run 不影响已加载的类
- 无法替代
composer update --dry-run：后者用于预览依赖升级，前者仅针对 lock 文件已有内容的安装模拟
