Composer 的 composer update vendor/package 默认不更新子依赖，因其依赖解析是“懒惰”的；--with-dependencies 仅将目标包的一级依赖纳入更新候选，非递归更新，也不保证升级，是否更新仍取决于版本约束与 lock 文件状态。
Composer 默认的 composer update 不会递归更新已满足版本约束的依赖，所谓“增量更新”并非原生行为，而是靠精准控制更新范围实现的；--with-dependencies 本身不实现增量，它只是让指定包的依赖也被纳入本次更新决策——用错场景反而导致过度更新。
为什么 composer update vendor/package 有时不更新其子依赖
Composer 的依赖解析是“懒惰”的：只要 vendor/package 的当前已安装版本仍满足 composer.json 中声明的版本约束（如 "^2.1"），且它的依赖（比如 monolog/monolog）也仍满足各自约束，就不会触发重安装或升级。
这意味着你手动改了 vendor/package 的版本号，但它的某个间接依赖卡在旧版（比如因其他包锁定），composer update vendor/package 也不会自动松动那个间接依赖——除非你显式让它参与决策。
- 只运行
composer update vendor/package：仅检查并更新该包自身，不触及其composer.json中定义的require - 加上
--with-dependencies：把该包直接依赖的包（一级依赖）也加入本次更新候选集，但不会递归到二级、三级 - 若想真正“增量式推进”，得配合
--with-all-dependencies或分步锁定 + 更新
--with-dependencies 的真实作用和典型误用
它不是“深度更新开关”，而是“扩大当前命令作用域”的标志：告诉 Composer，“除了我明确列出的包，也把它们的 require 列表里的包一起放进本次 solver 范围”。是否真更新，仍取决于版本约束和 lock 文件状态。
常见误用：
- 以为加了就一定能升到最新版 → 实际可能因冲突回退或保持原状
- 对多个包同时使用，却没意识到它们的依赖可能互相冲突 → solver 失败概率陡增
- 在 CI 中无条件加该参数 → 导致非预期的间接依赖漂移，破坏可重现性
正确姿势是：先确认你要更新的包是否真有新版本满足约束，再决定是否带依赖参与。
如何安全实现接近“增量更新”的效果
没有银弹，但可通过组合命令逼近目标：只更新目标包及其必要依赖，避免全量刷新。
- 先查清影响范围：
composer show vendor/package看其requires列表 - 尝试最小范围更新：
composer update vendor/package --with-dependencies --dry-run观察将变更哪些包 - 若输出中包含你不希望动的包（比如被其他组件强依赖的
symfony/polyfill），改用--with-all-dependencies并配合--prefer-lowest或--prefer-stable控制策略 - 更稳妥的做法是：先
composer require vendor/package:^3.0 --update-with-dependencies（Composer 2.2+），它比裸 update 更明确语义
composer update vendor/package --with-dependencies --dry-run
容易被忽略的关键点
--with-dependencies 不改变 solver 的约束优先级，也不绕过 composer.lock 的已有决议。如果你的 lock 文件里某个依赖被固定在 1.2.3，而 vendor/package 新版要求 ^2.0，那么这次 update 会失败，除非你先删 lock 或用 --ignore-platform-reqs（不推荐）。
真正需要“增量”时，往往意味着你已在维护一个长期演进的私有包生态，这时应考虑用 composer config minimum-stability dev 配合分支别名（dev-main as 3.0.x-dev），而非依赖每次手工 update。
