composer update --with-dependencies 已彻底移除，执行会报错“unrecognized option”，该参数从未进入 composer 正式发布版，仅短暂存在于 v1.x 实验分支，自 2.2+ 版本起源码中完全删除，官方文档、help 和 github 均无痕迹。
composer update --with-dependencies 已彻底失效，别再试了
执行 composer update --with-dependencies 会直接报错：Unrecognized option: --with-dependencies。这个参数在 Composer 2.2+ 中已被完全移除，源码里不存在，文档里不收录，所有“教程”类文章若还在教这个写法，内容已过期至少三年。
- 它从未是稳定功能，只短暂出现在 v1.x 的实验分支，没进过任何正式发布版
- Composer 官方 help 输出、GitHub issue 搜索、Packagist 文档均无此选项痕迹
- 看到别人用成功？大概率是本地还装着旧版 Composer（--with-all-dependencies 看成
--with-dependencies
真正能控制依赖更新范围的两个参数
想让某个包升级时连带更新它的依赖，必须用这两个明确存在的选项：
-
--with vendor/package：只把指定包及其 直系依赖（即该包自己composer.json的require列表）纳入本次求解范围。例如composer update monolog/monolog --with psr/log，不会动psr/log所依赖的psr/simple-cache -
--with-all-dependencies（或简写-W）：把目标包 + 它当前vendor/中已安装的 所有间接依赖（无论嵌套几层）都拉进重算。比如composer update monolog/monolog -W可能一路升到symfony/polyfill
注意：--with 后必须跟具体包名，不能空着；--with-all-dependencies 不接受值，也不能指定前缀匹配。
为什么加了 -W 还没更新到底层包？
常见现象：跑了 composer update foo/bar -W，但 vendor/symfony/console 没变。这不是参数失效，而是 Composer 严格守约：
- 那个包可能根本不在
foo/bar的依赖树里——它是“孤儿”，未被任何已安装包引用 - 其他包对它的约束太死，比如
guzzlehttp/guzzle锁死了"symfony/console": "5.4.*"，而foo/bar要^6.2，无交集则跳过 -
composer.lock里该包的source或dist字段没变，说明求解器判定无需更新
验证方法：先跑 composer show foo/bar 查它声明的 require，再顺藤摸瓜看那些包各自的依赖链；或者加 --dry-run 预览影响范围。
日常更新单个包，其实根本不需要 --with 参数
绝大多数场景下，你只需要：composer update vendor/package-name。Composer 默认就会更新目标包 + 它直系依赖中“不得不升”的部分（比如旧版 psr/log 不满足新 monolog 的 require），这是 SAT 求解器的自然行为，不是 bug。
- 加
--with-all-dependencies是主动扩大求解范围，风险集中：可能意外升级底层组件（如psr/log），导致运行时行为变化 - 多个主包共用同一底层依赖时，
-W容易因版本约束冲突失败，报错类似Conclusion: don't install symfony/console v5.4.39 - CI 环境中 lock 文件变动比预期大，diff 难以审查，可维护性下降
真正容易被忽略的是：Composer 的“递归更新”默认就存在，--with-all-dependencies 只是显式放开边界；而所谓“依赖的依赖”，从来不在逻辑之外——它只是你没意识到，默认就已经在做了。
