composer update vendor/package-name才是精准更新单个包的正确命令，它只解析目标包及其子依赖，不改变其他顶层包版本；而composer require会修改composer.json并重算整个依赖图，可能连带升级无关包或提升间接依赖为根级依赖。
composer require 不是用来更新单个包的，它本质是“添加或修改约束”，不是“升级已装包”。想精准更新，必须用 composer update vendor/package-name。
为什么 composer require vendor/package:version 不等于更新
这个命令会改 composer.json 里的版本字段，再触发一次完整安装流程——它可能重算整个依赖图，连带升级 psr/log、symfony/polyfill-php80 等你没打算动的包。更隐蔽的问题是：如果该包原本只是间接依赖（比如被 laravel/framework 拉进来的），require 会把它提到根级，改变依赖层级，后续维护容易混淆。
- 当前装的是
monolog/monolog v2.9.0，执行composer require monolog/monolog:^2.10后，composer.lock可能出现大量无关变更 - 若
composer.json原本没声明该包，require会新增一行，这不是“更新”，是“引入” - 想升到
v3.0.0却失败？大概率是现有约束（如"^2.8"）直接拦住了，require不会自动放宽它
composer update vendor/package-name 的真实行为
这才是真正可控的单包更新方式。它只解析目标包及其子依赖的版本约束，其他顶层包（如 laravel/framework、guzzlehttp/guzzle）的版本记录在 composer.lock 中保持不变。
- 必须写全名，例如
monolog/monolog，不能只写monolog，否则报错或静默失败 - 包名拼错（如
monolog/monolg）时，命令也静默成功，但vendor/和composer.lock都不动 - 它会升级该包的直系依赖（如
monolog新版 requirepsr/log ^2.0，而你锁的是1.1.4，那psr/log就会被一并升级） - 不会升级被其他包共用但未被该包新版本要求的依赖（比如
symfony/console没被monolog新版 require，就不会动）
如何预判和控制连带升级
执行前先看清楚它打算动什么，别等 CI 报错才后悔。
- 用
composer update monolog/monolog --dry-run预览变更，重点关注输出里有没有downgrading或非预期的laravel/、phpunit/包 - 用
composer show monolog/monolog查它的依赖树，确认关键子依赖（如symfony/console）是否可能被推高 - 若想彻底禁用子依赖更新（Composer 2.2+），加
--no-update-with-dependencies，但前提是这些子依赖当前版本已满足新要求，否则直接报错 - 升级后务必
git diff composer.lock，确认只变了目标包及其必要子依赖的行，尤其注意packages-dev区块是否被意外牵连
常见翻车点和绕过方法
最常卡住的不是命令写错，而是约束冲突或误判了依赖关系。
- 报错
Root composer.json requires vendor/package ^2.5, found ... 3.0.x-dev but these were not loaded？说明composer.json的约束太死，先composer show vendor/package看可用版本，再决定是否手动放宽约束 - 执行
composer update foo/bar没反应？检查composer.json里是否写了固定版本（如"foo/bar": "1.2.3"），或composer.lock是否已是最匹配版本 - CI/CD 里慎用
update：缓存可能导致不同 runner 行为不一致，建议在composer install前用composer.lock固定所有版本，而非靠update动态求解
真正难的不是敲对命令，而是读懂 composer why-not psr/log ^2.0 的输出、判断哪个包在拦路，以及接受一个事实：所谓“只更新一个包”，从来不是原子操作，而是依赖求解器在约束下给出的最小可行解——你得先看清约束，再决定要不要改它。
