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，完全没必要加这个参数——它会触发大量不必要的版本漂移，增加回归风险。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
--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。
