composer update --with-all-dependencies 会更新项目所有已安装依赖(含 require 和 require-dev 声明的直接依赖及其全部间接依赖),在不破坏原有约束前提下升至最高兼容版本,但不触碰孤儿包、不绕过 composer.lock、不解决 php 版本冲突。

composer update --with-all-dependencies 到底更新哪些包
它不是“把整个 vendor 递归重装一遍”,而是让 composer update 在解析依赖时,把当前项目 composer.json 中声明的所有直接依赖(包括 require 和 require-dev)及其**所有间接依赖的约束也一并放开**,允许它们升到符合新约束的最高兼容版本。
换句话说:原本 composer update foo/bar 只会动 foo/bar 及其直系子依赖;加了 --with-all-dependencies,等于告诉 Composer:“只要不破坏 foo/bar 的版本要求,它依赖的 baz/qux、baz/qux 依赖的 xyz/abc……全都可以升级”。
- 只对
composer update生效,composer install不认这个参数 - 不会更新 lock 文件里已锁定但未被任何 require 涉及的“孤儿包”(比如某个 dev 包卸载后残留的)
- 如果某间接依赖在多个路径上有冲突约束(比如 A 要求 v1.2,B 要求 v1.5),Composer 仍会报错,不会强行覆盖
什么时候必须用 --with-all-dependencies 而不是普通 update
典型场景是:你升级了一个主依赖(比如从 laravel/framework 9.x 升到 10.x),但发现 vendor 里一堆子包还是旧版,导致运行时报 Class not found 或 Method not exists —— 这往往是因为 Laravel 10 要求 symfony/console ≥6.2,而 lock 文件里还锁着 5.4。
- 你手动改了
composer.json里的某个包版本号,想让它连带的生态链一起刷新 - CI 环境跑
composer update失败,提示 “your requirements could not be resolved”,但你知道只是子依赖太老卡住了 - 想快速验证一个大版本升级是否可行,又不想逐个列所有子包名
反例:日常开发中仅修复一个小 bug 后执行 composer update,完全没必要加这个参数——它会触发大量不必要的版本漂移,增加回归风险。
--with-all-dependencies 和 --with-dependencies 的区别
--with-dependencies 是“有限递归”:只放开你显式列出的包(比如 composer update foo/bar --with-dependencies)所直接依赖的包;而 --with-all-dependencies 是“全局放开”:所有已安装包的约束都参与重新计算。
-
composer update foo/bar --with-dependencies→ 更新foo/bar+ 它的require列表里的包(一层) -
composer update foo/bar --with-all-dependencies→ 更新foo/bar+ 所有它依赖的包 + 这些包依赖的包……直到整个图收敛 - 两者都不影响没被任何
require引用的包(比如曾经装过、后来删了require行但没remove的)
错误认知:以为加了 --with-all-dependencies 就能绕过 composer.lock。其实它依然读 lock 文件做 diff,只是放宽了“哪些包允许动”的范围。
容易踩的坑和性能提醒
这个参数会让依赖解析器工作量指数级上升,尤其在大型项目里,可能卡住几十秒甚至超时失败。不是因为它“慢”,而是它在尝试更多合法组合。
- 别在没提交
composer.lock前执行,否则生成的 lock 差异巨大,Code Review 难以聚焦真实变更 - CI 中慎用:某些平台(如 GitHub Actions 默认 60 分钟超时)可能因解析卡住而失败,建议先本地跑通再推
- 如果只想升某几个关键子依赖(比如
symfony/*),不如直接composer update symfony/console symfony/http-kernel --with-dependencies更精准 - 执行后务必检查
git diff composer.lock,重点关注是否有意外降级或跨大版本(如monolog/monolog从 2.x 变成 3.x)
最常被忽略的是:它不会帮你解决 PHP 版本不兼容问题。比如你要升 doctrine/dbal 到 4.x,但 php:8.0 不满足其 php:8.1+ 要求,Composer 依然报错——得先调 config.platform.php 或升级 PHP。










