不能完全替代真实更新，但能暴露绝大多数依赖冲突和版本回退风险；它不下载包、不写入 vendor 或修改 composer.lock，仅解析+模拟安装，故不触发脚本、不校验平台配置、不检查扩展加载。
composer update --dry-run 能不能真正预演依赖变更？
不能完全替代真实更新，但能暴露绝大多数依赖冲突和版本回退风险。它不下载包、不写入 vendor 或修改 composer.lock，只做解析+模拟安装，所以不会触发脚本（如 post-install-cmd）、不校验平台配置（如 PHP 版本是否真满足 require），也不检查扩展是否已加载。
--dry-run 为什么有时报错而真实 update 却成功？
常见于两类情况：一是本地 composer.lock 已过期但未被检测（composer update --dry-run 默认不强制刷新 lock 文件，需加 --lock）；二是某些插件或自定义 installer 在 dry-run 模式下跳过逻辑，导致约束判断不一致。
- 务必搭配
--with-dependencies使用，否则只检查 root 包，漏掉子依赖的降级风险 - 遇到
Your requirements could not be resolved但实际能更新时，先运行composer update --dry-run --lock看是否因 lock 过期误判 - PHP 版本/扩展限制类错误（如
ext-gdrequired）在 dry-run 中不会报，得靠composer check-platform-reqs单独验证
如何用 --dry-run 发现隐性安全降级？
Composer 不会主动标出“这个包从 v2.3.1 降到 v2.1.0”，但你可以通过对比输出快速识别：dry-run 的最终解析结果里，如果某个包的版本号比当前 composer.lock 里记录的旧，就属于降级——这可能引入已知漏洞（比如 v2.1.0 有 CVE，v2.3.1 已修复）。
- 执行
composer update --dry-run --no-ansi | grep "downgrading"直接抓降级行 - 配合
composer show vendor/package查看历史安全通告，确认降级包是否含已修复 CVE - 注意
require-dev里的包也会被解析，dev-only 的降级同样可能影响测试环境安全性
替代方案：比 --dry-run 更可靠的预检组合
单一 --dry-run 容易漏掉 lock 文件陈旧、平台不兼容、脚本副作用三类问题。生产环境更新前，建议串行执行：
-
composer validate—— 确保composer.json语法和字段合法 -
composer check-platform-reqs—— 验证 PHP、扩展、INI 设置是否达标 -
composer update --dry-run --lock --with-dependencies—— 锁文件同步 + 全依赖解析 -
composer audit（需 composer 2.5+）—— 直接扫描已知漏洞，不依赖更新动作
真正麻烦的不是命令怎么敲，而是很多人把 --dry-run 当成“不会出事”的保险，其实它连 autoloader 是否仍能生成都不验证。改完依赖后，至少跑一次 composer dump-autoload --no-scripts 再确认类加载没崩。
