直接运行 composer update vendor/package-name 是最可靠方式；若无更新，通常因版本约束过严，需检查并调整 composer.json 中对应包的版本号。
composer update 只更新一个包，不是加 --only 也不是 --with
Composer 没有 --only 或 --with 这类参数，强行加会报错：Unrecognized option "--only"。想只更新某个包，得靠「精确指定包名」+「避免触发依赖连带更新」。
- 直接运行
composer update vendor/package-name（比如composer update monolog/monolog）是最可靠的方式 - 如果该包被其他已安装包在
require中硬依赖（比如laravel/framework锁死了symfony/console的版本），它可能不会升级——Composer 会优先满足 root 的约束，而非你“想升”的意愿 - 加上
--with-dependencies是危险操作：它会让 Composer 把这个包的所有子依赖也拉进来更新，很可能意外升级一堆东西 - 别用
composer require vendor/package-name:version --update-with-dependencies来“曲线救国”，这本质是重装，可能改写composer.json里的约束，后续install行为会变
为什么 composer update foo/bar 有时没反应？
表面执行成功，但 vendor/foo/bar 文件没变、composer.lock 也没动——大概率是当前 composer.json 里对该包的版本约束太死，或者 lock 文件里已经满足最新可用版本。
- 检查
composer.json中是否写了类似"foo/bar": "1.2.3"（完全固定）或"^1.2.0"但最新稳定版仍是1.2.3 - 运行
composer show foo/bar看当前安装版本，再跑composer show -a foo/bar查所有可用版本，确认有没有更高版可选 - 如果真想突破约束升级，得先手动改
composer.json里的版本号（比如从"^1.2"改成"^1.3"），再执行composer update foo/bar - 注意：改完
composer.json后不加包名直接composer update，会按新约束全量重算依赖，不是只动这一个包
想升级但怕 break，怎么安全试跑？
最有效的办法不是看文档，是让 Composer 自己告诉你“这次会动什么”。
- 加
-n（--no-interaction）和--dry-run组合：运行composer update foo/bar --dry-run -n，它会输出将要安装/降级/跳过的包列表，不写磁盘 - 如果输出里出现大量其他包，说明这个包的升级牵扯大，尤其留意是否有
downgrading（降级）或removing（移除）——那基本等于接口不兼容 - 临时切分支再试：
git checkout -b try-update-foo-bar，跑 update，有问题git reset --hard && git checkout -就完事，比 rollback lock 文件干净 - CI 中不要用
--dry-run做判断依据：它的输出格式不稳定，不同 Composer 版本差异大，脚本解析容易翻车
lock 文件被改了但 vendor 没更新？
这是常见错觉。Composer 的行为是原子的：composer update 要么同时更新 composer.lock 和 vendor/，要么都不动。如果你看到 lock 变了但 vendor 没变，八成是以下情况之一：
- 执行的是
composer update --lock（只重写 lock 文件，不装包），这个命令极少用，但有人误传 - 你用的是 Composer 2.2+，启用了
lock.files配置，指向了非默认 lock 文件，而vendor是按默认composer.lock装的 - 文件系统权限问题：
vendor/目录不可写，Composer 写 lock 成功了，但复制文件失败，控制台会明确报Could not delete ...类错误，别忽略它 - IDE 或编辑器在你运行命令时锁住了某些 .php 文件，导致 Composer 移动失败（Windows 上尤其多见）
composer.json 里那个包的版本约束到底允不允许升——盯着那一行看三秒，比查十篇教程管用。 
