composer update --dry-run 是轻量级依赖健康检查工具，完整模拟解析逻辑但跳过写入操作，可暴露冲突、不兼容及意外升级，需配合参数和测试使用。

为什么 composer update --dry-run 不只是“看看而已”

它真正的作用是提前暴露依赖冲突、版本不兼容和意外升级路径，避免直接跑 composer update 后卡在半途或破坏生产环境行为。很多团队把它当“预览”，其实它是 CI/CD 流水线里最轻量的依赖健康检查入口。

--dry-run 会模拟哪些关键操作

它完整复现 composer update 的解析逻辑：读 composer.json、查 composer.lock、连 Packagist 或私仓、计算依赖图、执行版本约束求解——但跳过下载、解压、写入 vendor/ 和更新 composer.lock。所以你能看到：

• 哪些包会被升级/降级（含次版本号变化，比如从 2.3.1 到 2.4.0）
• 哪些包被锁死（Keeping x/y (v1.2.3)）
• 哪些包因冲突被拒绝（Skipped x/y: version constraint ... is not satisfied）
• 是否触发了 replace 或 provide 规则的替换行为

常见误用与真实风险点

很多人只扫一眼“Will update X packages”，却忽略几个隐蔽但致命的细节：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• --dry-run 默认仍会尝试访问远程仓库——如果私仓不可达或认证失效，它会报错退出，而不是静默跳过
• 它不校验 autoload 变更影响：比如某包升级后移除了一个类，--dry-run 不报错，但后续 composer dump-autoload 可能失败
• 对 require-dev 中的工具类包（如 phpunit/phpunit）同样生效——容易误升测试框架主版本，导致 tests/ 全红
• 如果本地有未提交的 composer.lock 修改，--dry-run 的结果可能和实际 update 不一致（它基于当前 lock 文件状态计算）

配合其他参数才真正高效

单独用 --dry-run 信息密度低，加一两个参数立刻聚焦问题：

• composer update --dry-run --with-dependencies vendor/package：只看某个包及其传递依赖的变化，适合验证局部升级
• composer update --dry-run -v：显示详细版本决策日志，能看清为什么某个包没升（比如 “because your project requires it”）
• composer update --dry-run --no-plugins：禁用插件，排除自定义 installer 或脚本干扰，排查锁定异常时很有用
• CI 中建议加 --ignore-platform-reqs（如果目标环境 PHP 版本和本地不同），否则可能漏掉平台不兼容警告

真正要注意的是：它不代替测试。哪怕 --dry-run 完全通过，也要跑单元测试+集成测试——因为语义化版本规则无法覆盖所有 BC break 场景。