composer update 只更新一个包的正确写法
直接运行 composer update vendor/package-name 就行，不需要加任何 flag 或配置。这是 Composer 原生支持的最简方式，不是 hack，也不是临时方案。
常见错误是写成 composer update --with-dependencies vendor/package-name 或试图用 --only，但 Composer 根本没有 --only 这个选项；--with-dependencies 会连带升级它的依赖（可能触发意外升级），多数时候反而违背“只更新一个”的初衷。
- 必须写全包名，格式为
vendor/name，比如monolog/monolog、laravel/framework - 如果包名写错或本地没安装过，命令会静默成功但不执行任何操作——不会报错，容易误以为更新了
- 该命令只更新
composer.json中已声明的包；如果包是间接依赖（没出现在你的composer.json里），不能这样更新
为什么 composer require vendor/package:version 不等于更新
composer require 是“添加或修改版本约束”，不是“拉取新版本”。它会改 composer.json 的 version 字段，再执行 install，行为和 update 有本质区别。
比如当前装的是 symfony/console v5.4.0，你想升到 v5.4.32：
- 用
composer update symfony/console→ 直接升级到符合约束的最新5.4.x版本 - 用
composer require symfony/console:^5.4.32→ 先改composer.json，再 install；但如果锁文件里已有v5.4.30且满足^5.4.32（实际不满足，但 Composer 有时会误判兼容性），可能根本不升级
真正想“精准升到某版”，得配合 --with-all-dependencies 或手动改 composer.lock，但风险高，不推荐。
更新单个包时 lock 文件怎么变
执行 composer update vendor/package-name 后，composer.lock 里只有该包及其**直接依赖中被牵连变动的部分**会更新。其他包的版本记录保持不变。
这意味着：如果你的项目里有两个包都依赖 psr/log，而你只更新 monolog/monolog，那么 psr/log 是否升级，取决于 monolog 新版本的 require 字段是否放宽或收紧了对 psr/log 的约束。
- 如果
monolog新版要求psr/log:^2.0，而旧版只要求^1.0，且你当前锁的是1.1.4，那psr/log会被一并升级 - 如果只是小版本更新（如
7.2.1 → 7.2.3），且依赖约束没变，psr/log等间接依赖通常不动 - 锁文件变化量小，适合 code review；但别假设“只改了一行”——要看 diff，尤其注意
packages-dev区块是否也被动变了
CI/CD 里慎用 update 单个包
在 GitHub Actions、GitLab CI 这类环境里，composer update vendor/package 容易因缓存或并发导致行为不一致。比如 Composer 缓存了旧的 dist 包，又没清干净，可能装上一个“看似新实则旧”的版本。
更稳的做法是：先 composer clear-cache，再跑 update；或者干脆用 composer install --no-cache + 提前 commit 更新后的 composer.lock。
- CI 中不要依赖“本地开发机跑过一次 update 就万事大吉”——lock 文件必须真实反映最终结果
- 如果包有 post-update-cmd 脚本（比如 Laravel 的
php artisan vendor:publish），它不会自动触发；得手动加步骤 - 某些私有包源（如 Satis、Private Packagist）若未配置 token，update 可能卡住或降级到旧版，错误信息就一行：
Could not fetch https://xxx/…，不容易发现
真要自动化更新单个包，优先走 lock 文件 diff + 人工审核流程，而不是靠一条命令赌稳定性。
