告别版本焦虑：利用Composer Dry Run功能安全预览更新变更

告别版本焦虑：利用Composer Dry Run功能安全预览更新变更

在依赖管理这件事上，最让人提心吊胆的莫过于一次不经意的 composer update。你猜怎么着？其实Composer早就提供了一个“安全气囊”——--dry-run 参数。它不会真正安装或修改任何文件，却能完整模拟出 update 或 install 命令会触发的所有包变更。这相当于在按下“确认”按钮前，先拿到一份详细的变更清单，是判断一次更新是否安全、是否引入破坏性依赖的最轻量级、也最有效的验证手段。

什么时候必须加 --dry-run？

当你准备执行 composer update 时，如果项目处于以下几种状态，那么跳过 --dry-run 就无异于蒙着眼睛部署生产环境：

• 主分支有未合并的 PR，正等着依赖兼容性的最终确认。
• composer.json 里使用了模糊的版本约束，比如 "^2.0"、"dev-main" 或 "*@dev"。
• 上一次提交 composer.lock 文件已经是两周前的事了，而且团队协作频繁。
• CI流水线突然报出类似 Root package requires ... but it is not installed 的错误，需要快速定位是不是本地的 lock 文件已经过期了。

composer update --dry-run 看懂这三行关键输出

运行命令后，终端不会显示“成功”，而是列出一份拟变更的包清单。这时候，你的注意力需要聚焦在以下三类关键行上：

• 以 Updating ... 开头的行：这表示该包将被升级，版本号会发生变化。例如 Updating monolog/monolog (2.9.1 => 3.0.0) —— 注意，这里的 3.0.0 是一个主版本号变更，通常意味着可能存在破坏性更新，务必去查看该包的 UPGRADE.md 文件。
• 以 Downgrading ... 开头的行：这种情况比较少见，但往往更危险。它通常意味着某个间接依赖被强制降级了，很可能会引发方法缺失或行为回退。
• 以 Installing ... 或 Removing ... 开头的行：这说明依赖图的结构发生了变动。比如，某个包的新版本移除了对 symfony/console 的依赖，或者新增了对 ext-redis 扩展的要求。

需要警惕的是，--dry-run 本身不会检查系统扩展是否已启用，也不会执行任何 post-update-cmd 脚本——它的工作仅限于依赖解析和版本比对。

和 composer show --outdated 的本质区别在哪？

很多人会混淆这两个命令。简单来说，composer show --outdated 只告诉你“哪些包有新版本”，但它完全不反映实际的更新路径。而 --dry-run 则是完整地走了一遍Composer的依赖求解器（SAT solver），其结果具备真实的执行效力。这其中的区别，主要体现在几个方面：

• show --outdated 可能会显示 guzzlehttp/guzzle: 7.8.0 => 7.8.1，但 --dry-run 可能会发现，由于 lara vel/framework 锁定了某个 guzzlehttp/psr7 的版本，最终导致 guzzlehttp/guzzle 实际上无法升级。
• 有些包在 --outdated 的列表里不会出现，却会在 --dry-run 中被连带更新。例如，你只是修改了 phpunit/phpunit 的版本约束，结果可能触发整个测试工具链的重新计算。
• --dry-run 会暴露 conflict 规则的实际生效情况。比如，当求解器触发 Package foo conflicts with bar >=2.0 时，--dry-run 会如实反映，而 --outdated 则完全无视这些冲突声明。

容易被忽略的两个边界场景

--dry-run 虽然快速高效，但绝非万能。有两个关键点如果只依赖它而不做手动验证，项目照样有翻车的风险：

• 它不校验 autoload 配置变更：如果某个包的新版本把源代码目录从 src/ 改成了 lib/，或者删除了某个PSR-4映射，--dry-run 不会报错。但后续执行 composer dump-autoload 时，自动加载就可能失败。
• 它不处理平台配置漂移：比方说，你本地的 php.ini 关闭了 extension=mbstring，而某个新依赖却在 require 里声明了 "ext-mbstring": "*"。这种情况下，--dry-run 会安静通过，等到真正执行安装时，才会抛出 Your requirements could not be resolved 的错误。

所以说，真正安全的依赖更新节奏应该是这样的：先用 composer update --dry-run 预览变更；然后人工核对关键包的 CHANGELOG 或升级指南；最后，在一个可控的环境（如CI或Docker容器）中，执行一次真实的 composer install 并运行完整的单元测试。这才是确保项目平稳升级的关键所在。