--dry-run 是 Composer 的安全预演命令，用于提前识别依赖冲突、版本不兼容、扩展缺失等风险，必须在拉分支、CI检查、PR评审等关键场景强制执行。
--dry-run 不会装任何包，也不会改任何文件，但它能告诉你“如果真执行，Composer 会干啥”——这是你上线前、合代码前、加依赖前最该跑的一条命令。
什么时候必须用 composer install --dry-run？
不是“可选”，而是“不跑就容易翻车”的场景：
- 刚拉完新分支，
composer.json或composer.lock有变动，想确认会不会意外升级symfony/console到 v7（而你的 PHP 还是 8.1） - CI/CD 流水线里，想在
composer install前加一道检查：如果解析出要装ext-gd但当前环境没启用，就直接失败 - 团队协作中收到 PR 修改了
require-dev，你不想本地install后才发现phpunit把sebastian/environment升级到了不兼容版本
composer require --dev --dry-run 的真实价值
它不只是“看看要装啥”，而是帮你拦截开发依赖引发的隐性破坏：
- 运行
composer require --dev phpunit/phpunit --dry-run时，输出里如果出现will update doctrine/instantiator from 1.5.0 to 2.0.0，就得立刻查文档——v2 是 PHP 8.1+ only，而你项目还跑在 8.0 上 - 如果看到
will remove myproject/utils，说明新包和你已有的工具类存在自动加载冲突或命名空间重叠，不是版本问题，是结构问题 - 它不会触发
post-autoload-dump脚本，所以即使预览时看到“会生成新的 autoload 文件”，也代表真实安装后可能因脚本失败而中断
composer update --dry-run 为什么比 composer show --outdated 更关键？
show --outdated 只告诉你“哪些包有新版”，而 update --dry-run 告诉你“更新后整个依赖树会变成什么样”：
- 它会模拟锁文件重写过程，显示
composer.lock中哪些包的content-hash、platform或dist.reference会被修改 - 输出中若出现
downgrading myvendor/package (dev-main → v3.2.1)，说明约束冲突导致 Composer 回退版本——这往往意味着你写的^4.0和某个间接依赖的~3.0碰上了，不干预就会丢功能 - 加
-v参数（即composer update --dry-run -v）能看到解析器决策日志，比如：Trying monolog/monolog:3.0.0 -> satisfiable by monolog/monolog[3.0.0]，这对排查“为啥没装上我要的版本”极其有用
容易被忽略的细节和坑
很多人以为 --dry-run 就是“安全模式”，其实它有边界：
- 它不校验实际网络可达性——预览成功不代表
packagist.org没被墙，也不代表私有仓库 token 有效 - 它跳过所有
scripts执行，所以不会触发post-install-cmd里的数据库迁移检查，也不会运行phpstan静态分析 - 如果你用了
path类型仓库（如本地开发包），--dry-run仍会尝试读取其composer.json，但不会验证路径是否存在——路径错，预览照样过，真装时才报错 -
composer install --dry-run默认基于现有composer.lock，而composer update --dry-run忽略 lock 文件重新解析——别混用场景
真正起作用的从来不是“知道有这个参数”，而是把它塞进你的日常节奏：每次改完 composer.json，先 --dry-run；每次准备部署，CI 里加一行 composer install --dry-run 并设为失败退出码非零；每次 Review 依赖相关 PR，第一眼就看 --dry-run 输出有没有降级或平台变更。
