--with-dependencies 是 composer update 的参数，用于递归更新指定包及其直接依赖；默认只更新包本身，加此参数才同步升级其 composer.json 中声明的 require 项（未锁死时）。
composer update --with-dependencies 是什么
它不是独立命令，而是 composer update 的一个可选参数，用来控制「是否递归更新当前包所依赖的子依赖」。默认情况下，composer update vendor/package 只更新该包本身，不碰它的依赖；加了 --with-dependencies，Composer 就会把 vendor/package 的 composer.json 里声明的所有 require 项也拉进来一起更新（只要它们没被锁死在 composer.lock 中）。
什么时候必须加 --with-dependencies
常见于你明确想升级某个包，并且希望它用上新版依赖带来的修复或特性，比如安全补丁、PHP 8.2 兼容性改进等。但要注意：它只对「直接指定的包」生效，不会全局触发所有依赖更新。
- 你运行
composer update monolog/monolog，但发现psr/log还是旧版 → 加--with-dependencies才可能升级它 - 你改了
monolog/monolog的版本约束（比如从^2.8改成^3.0），但composer update monolog/monolog没升级成功 → 很可能是子依赖（如php版本要求）冲突，加--with-dependencies并配合-v能看到具体卡在哪 - CI 环境中想确保某组件及其生态链都走最新兼容组合 → 必须显式加这个参数，否则容易漏掉间接依赖的更新
不加 --with-dependencies 时的典型错误现象
最常遇到的是「看似更新成功，实际行为没变」：比如你升级了 guzzlehttp/guzzle 到 7.8，但代码里调用 GuzzleHttp\Client::send() 仍报错说找不到新方法——因为底层 psr/http-client 还卡在 1.0，而 7.8 要求 1.1+。Composer 默认不碰它，除非你告诉它「连带更新依赖」。
- 错误信息示例：
Your requirements could not be resolved to an installable set of packages.—— 实际是子依赖版本太老，和你要升的主包不兼容 -
composer show guzzlehttp/guzzle显示已升级，但composer show psr/http-client仍是旧版 → 就是没触发子依赖更新 - 本地开发 ok，测试环境失败 → 很可能 CI 没加
--with-dependencies，导致子依赖版本不一致
实际执行时的关键细节
这个参数不能单独存在，必须跟在 composer update 后面，并且后面要接具体的包名（或 all）。它和 --with-all-dependencies 不同：后者会无差别更新整个依赖树，风险更高；前者只影响你点名的那个包及其直接 require 的包。
- 正确写法：
composer update symfony/console --with-dependencies - 错误写法：
composer update --with-dependencies（没指定包名，会报错） - 如果想一次更新多个包并各自带子依赖：
composer update symfony/console laravel/framework --with-dependencies - 加
-v或--dry-run非常重要，能提前看到哪些子依赖会被动更新，避免线上误操作
真正麻烦的不是参数本身，而是它暴露出来的隐性约束：比如某个子依赖要求 PHP >= 8.1，而你服务器还是 8.0 —— 这时候加不加 --with-dependencies 都会失败，只是不加时你根本意识不到问题出在这儿。
