--dry-run 是 Composer 的模拟执行模式，完整运行依赖解析、版本决策等流程但跳过文件写入；支持 update、require、remove、install 等所有修改项目状态的命令，配合 -v 可揭示降级、冲突等隐藏风险，但无法检测网络、PHP 运行时及 autoload 配置问题。
composer --dry-run 是什么？它不执行，但比执行还重要
--dry-run 不是“假装运行”，而是让 Composer 完整走完依赖解析、版本决策、脚本规划等全部逻辑，只跳过写文件这一步——不改 vendor/，不重写 composer.lock，不执行 autoload 生成，也不建软链接。它输出的不是“可能”，而是「这次 update / require / remove 真正会干的事」。
哪些命令支持 --dry-run？别只记得 update
它覆盖所有会修改项目状态的命令，不是 update 专属：
-
composer update --dry-run：看哪些包要升/降/删，lock 文件哪几行会变 -
composer require monolog/monolog:^3.0 --dry-run：预览新增依赖是否拉进冲突包、是否会强制升级已有包 -
composer remove guzzlehttp/guzzle --dry-run：确认有没有其他包强依赖它，删了会不会连带卸载一堆东西 -
composer install --dry-run：检查当前composer.lock是否能被当前 PHP 版本和平台配置满足（比如发现ext-redis缺失但 lock 里有要求）
为什么加 -v（verbose）几乎总是必要的
默认 --dry-run 只显示增(+)、改(~)、删(-)的包名和版本，但你看不到「为什么」。加 -v 后，它会打印依赖树解析过程、版本约束冲突点、回退到哪个候选版本、甚至哪个 conflict 规则被触发。没有 -v，你可能以为一切正常，其实它已悄悄把 symfony/console 从 v6 降级到了 v5.4——而你的代码用了 v6 的新 API。
常见错误现象：composer update --dry-run 输出看起来干净，上线后却报 Class not found；加了 -v 才发现某关键包被间接降级了。
--dry-run 看不见的三类风险，必须人工核对
--dry-run 再准，也只模拟 Composer 自身行为。以下问题它不会预警，但上线就炸：
-
网络与权限：它不测试能否真正下载包（比如私有仓库 token 过期、公司代理拦截）、也不检查
vendor/目录是否可写 -
PHP 运行时兼容性：它知道
"php": "^8.1"，但不知道你启用了opcache.enable=1且没清缓存，导致新类加载失败 -
autoload 边界失效：它不生成或验证
vendor/autoload.php，所以不会告诉你 PSR-4 映射漏配、或某个files加载的函数被删了但没报错
composer update，而是先 composer update --dry-run -v，再扫一眼变更里有没有 major 版本跃迁、有没有非预期的 downgrades，最后手动查一遍目标包的 CHANGELOG —— 这三步少一步，都可能让下一次 CI 失败变成深夜告警。 
