composer update –dry-run 是 Composer 的模拟更新命令，不修改文件但完整解析依赖并输出将执行的操作，用于上线前验证、排查冲突、避免误升级；必须用于生产部署前、团队协作审查、解决依赖报错、CI预检等场景。
composer update --dry-run 是 Composer 提供的「只看不改」模式，它不会真正下载、安装或修改任何文件，但会完整模拟一次 composer update 的依赖解析过程，并输出将要执行的操作。这是上线前验证更新影响、排查冲突、避免误升级的关键步骤。
什么时候必须用 --dry-run
不是所有 update 都需要加 --dry-run，但以下场景强烈建议：
- 生产环境部署前，确认
composer update是否会意外升级主版本（如从monolog/monolog:^2.0升到^3.0） - 团队协作中，有人提交了新的
composer.json变更，你想快速判断它会拉哪些新包、删哪些旧包 - 遇到
Your requirements could not be resolved报错时，加--dry-run可配合-v查看完整依赖树推导过程 - CI 流水线中做预检（例如在
pull_request时运行composer update --dry-run --no-interaction）
--dry-run 和 --what-if 的区别
注意：--what-if 是旧版 Composer（–dry-run。两者行为相似，但 --dry-run 更可靠，且支持全部 update 子命令逻辑（包括 --with-dependencies、--prefer-stable 等）。
常见误区是以为 --dry-run 仅“打印列表”，其实它会：
- 读取当前
composer.lock和composer.json - 重新执行依赖约束求解（和真实 update 完全一致）
- 计算出完整的 install / update / remove 操作序列
- 但跳过文件写入、脚本执行、autoloader 重建等副作用
实战：用 --dry-run 快速定位风险升级
假设你执行了：
composer update --dry-run -v输出中重点关注三类行：
-
Updating vendor/package (1.2.3 => 2.0.0)→ 主版本跃迁，需检查 BC break -
Downgrading vendor/other (3.1.0 => 2.9.5)→ 因依赖冲突被降级，可能引发功能缺失 -
Installing new package/name (v4.2.1)→ 新增包，确认是否在白名单内
如果只想看某几个包的模拟结果，可限定范围：
composer update --dry-run symfony/console guzzlehttp/guzzle这样既加快响应，又避免被无关包干扰判断。
容易忽略的细节和限制
--dry-run 不等于「零成本」——它仍会触发网络请求（访问 packagist.org 或私有源）、解析大量 JSON 元数据、执行 php 代码（如自定义 repositories 中的 PackageRepository 类），所以首次运行可能较慢。
另外要注意：
- 它不会检测本地
vendor/文件是否被手动修改（比如你删了某个包的文件），这种状态差异只有真实install才会暴露 - 如果项目启用了
config.platform，--dry-run会严格按该平台模拟，这点比肉眼检查composer.json更准 - 它不显示 post-update-cmd 脚本内容，哪怕这些脚本在真实 update 中会执行数据库迁移或清缓存
真正要落地更新，永远先 --dry-run，再 git diff composer.lock，最后才 composer update。漏掉中间任一环，都可能让一次小更新变成线上事故。