正确做法是运行 composer update vendor/name（如 composer update monolog/monolog），它会严格遵循 composer.json 中该包的版本约束进行更新，必要时需手动调整版本号并确保 composer.lock 同步。
composer update 只更新一个包，不是加 --only
Composer 没有 --only 这种参数，加了会报错 Unrecognized option "--only"。想单独更新某个包，得靠指定包名本身——不是“排除其他”，而是“只提这个”。
常见错误是写成 composer update --dry-run 看效果，结果发现没锁版本，顺手把一堆依赖全升了；或者误以为 composer require vendor/name 能升级，其实它只在没安装时才装，已存在且满足约束时直接跳过。
- 正确做法：运行
composer update vendor/name（例如composer update monolog/monolog） - 它会尊重
composer.json中该包的版本约束（比如"monolog/monolog": "^2.8"），只在这个范围内找最新版 - 如果想强制升级到某个具体版本，先改
composer.json里的版本号，再跑composer update vendor/name - 加
--with-dependencies会连带更新它的直接依赖（谨慎用，可能引发连锁升级）
更新失败时先看 lock 文件和版本约束冲突
执行 composer update vendor/name 报错，十有八九不是命令写错了，而是版本解不开。Composer 不是“下载最新版”，而是在整个依赖图里找一组能共存的版本。
典型现象：Root composer.json requires vendor/name ^3.0, found vendor/name[dev-main, 4.0.x-dev] but these were not loaded —— 说明你写的约束太窄，新版本根本进不来。
- 先检查
composer.json里该包的版本字符串，是否写死了"1.2.3"或用了~1.0这类窄范围 - 用
composer show vendor/name看当前装的是哪个版本、有哪些可选版本 - 临时放宽约束（比如从
"^1.2"改成"^1.0 || ^2.0"），再试composer update vendor/name - 别忽略
composer.lock：如果它锁着旧版本，而composer.json又没改，update实际不会动
require --update-with-dependencies 和 update 的区别
composer require vendor/name:version --update-with-dependencies 看起来像升级，但它本质是“假装重新装一遍”，行为和 update 不同。
它会尝试把目标包及其所有子依赖都升到满足新约束的最新版，容易突破原有兼容边界。而 composer update vendor/name 默认只更新该包及其直系依赖（不递归），更可控。
- 用
require --update-with-dependencies前，先git diff composer.json确认你真想改约束 - 它会自动修改
composer.json，如果你只是想试升级，不如手动改完再update - 如果项目里有
platform配置（比如"php": "8.1"），require --update-with-dependencies可能无视它去拉不兼容的包，update则更守规矩
CI/CD 里更新单个包要小心缓存和 lock 文件
在 GitHub Actions 或 GitLab CI 里跑 composer update vendor/name，常遇到“明明改了 composer.json 却没生效”，其实是缓存或工作流顺序问题。
- 确保
composer install前没有composer.lock缓存污染——有些流程会缓存整个vendor/，导致update根本不触发 - 如果 CI 是基于
composer.lock安装的，那update必须生成新 lock 才有效；记得把新composer.lock提交回去，否则下次 CI 还是旧版 - 避免在 CI 里用
--no-interaction --no-ansi以外的选项，像--dry-run在 CI 里看不到输出，等于白跑
cat composer.json 和 cat composer.lock | head -20 对一眼。 
