composer如何使用–dry-run测试更新_composer预演依赖变更影响【安全】

不能完全替代真实更新，但能暴露绝大多数依赖冲突和版本回退风险；它不下载包、不写入 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-gd required）在 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 再确认类加载没崩。