Composer无原生增量安装命令，本质是控制更新范围并避免全量重算依赖树；直接require或update均会触发全量解析，需用--no-update+显式锁定+局部update组合实现可控增量。
Composer 没有原生的“增量安装”命令，所谓增量，本质是**控制更新范围 + 避免全量重算依赖树**。直接运行 composer update 会重新解析整个依赖图、升级所有满足约束的包，这不是增量，是“重拍版”。真要只动目标包及其直系依赖，得靠参数精准干预。
为什么 composer require vendor/package 不等于增量安装
它确实只加一个包，但会连带触发全量依赖重解析：Composer 会读取当前 composer.json 和 composer.lock，把新包及其所有依赖纳入 solver，可能意外升级你没想动的间接依赖（比如 monolog/monolog 从 2.8.0 升到 2.9.0）。这在生产环境容易引发兼容性问题。
- 现象：执行
composer require foo/bar后，composer.lock里几十个包版本都变了 - 原因：solver 必须保证整个依赖树仍满足所有版本约束，旧 lock 中的间接依赖若被新包“拉高”约束，就会被动升级
- 规避方式：先用
composer show foo/bar查看其require列表，再人工确认是否接受这些依赖的变动
composer update vendor/package --with-dependencies 的真实行为
这个组合才是接近“增量”的操作，但它只影响一级依赖，不递归。例如 laravel/framework 依赖 symfony/http-foundation，那么加上 --with-dependencies 会让后者参与本次决策，但不会管 symfony/http-foundation 自己依赖的 psr/cache 是否升级。
- 它不强制升级：是否真更新，取决于
composer.json约束和 lock 文件中已有版本是否还“合法” - 它不解决锁死冲突：如果
psr/cache被另一个包锁定在1.0.1，而laravel/framework新版要求^2.0，这条命令会报错，不会自动松动psr/cache - 典型误用：把它当“深度更新开关”，结果该升的没升，不该升的乱升
真正可控的增量推进：分步锁定 + 局部更新
想只升级 vendor/a 及其直接依赖，同时确保其他包纹丝不动，必须先“冻结”无关部分。核心思路是：用 composer require 锁定版本号，再局部更新。
- 步骤一：明确你要升级的目标包版本，比如
vendor/a:^3.2，运行composer require vendor/a:^3.2 --no-update（--no-update阻止立即重算） - 步骤二：手动编辑
composer.json，把其他所有你想保留的包（尤其是间接依赖）显式写进require并固定版本，如"monolog/monolog": "2.8.0" - 步骤三：运行
composer update vendor/a --with-dependencies，此时 solver 只能在你锁定的范围内找解，不会乱动其他包 - 注意：此法对 lock 文件敏感，操作前建议备份
composer.lock
最易被忽略的一点：Composer 的“懒惰解析”只在 install 和 update 的边界起作用；一旦你改了 composer.json，哪怕只加一个空格，下次 update 就可能触发全量重算——增量不是状态，是每次命令的精确参数组合。
