正确写法是 composer update vendor/package-name（如 monolog/monolog），必须带 vendor 名；它只更新指定包及其依赖，不修改 composer.json 结构，比 require --update-with-dependencies 更安全可靠。
composer update 更新指定包的正确写法
直接运行 composer update 会更新 composer.lock 中所有满足版本约束的依赖，不是你想要的。要只更新某个插件（即某个包），必须显式列出它的完整包名（vendor/name 格式）。
- ✅ 正确命令：
composer update vendor/package-name（例如：composer update monolog/monolog） - ⚠️ 注意：不能只写
package-name，必须带 vendor 名，否则报错Package "package-name" not found - ? 如果包名含斜杠但你不确定 vendor 名，可先查
composer show或看composer.lock里已安装项的 key - ? 执行时 Composer 仍会解析依赖图，若该包被其他已锁版本包强约束（如
"foo/bar": "1.2.3"写死在composer.json），则可能无法升级到更高版本
为什么 composer require vendor/name --update-with-dependencies 不是标准做法
composer require 的本质是「添加或修改 composer.json 并更新」，它默认会把包写进 require 段并触发全量更新逻辑。加 --update-with-dependencies 只是让其顺带更新该包的子依赖，但副作用大：
- ❌ 它会强制重写
composer.json—— 即使包已存在，也会再写一遍（可能改格式、顺序，甚至覆盖手动加的注释） - ❌ 若该包已在
require-dev，require命令默认把它移到require，行为不可控 - ✅ 真正安全的做法仍是
composer update vendor/name，它只读取现有声明，不改动composer.json结构
更新时遇到 “nothing to install or update” 怎么办
这通常不是命令写错了，而是当前 composer.lock 已满足 composer.json 中对该包的版本约束（比如写的是 "^2.0"，而 lock 里已是 2.4.1），Composer 认为无需操作。
- ? 先确认目标版本是否真的可用：
composer show vendor/name查当前装的版本；composer show vendor/name --all查所有可安装版本 - ? 想强制升到某具体版？改
composer.json里的版本号（如从"^2.0"改成"^2.5"），再跑composer update vendor/name - ? 想清掉旧约束直接拉最新兼容版？删掉
composer.lock中对应包的条目（或整个文件），再执行composer update vendor/name—— 但慎用，会影响其他包一致性
更新单个包时 --with-all-dependencies 的实际影响
加上 --with-all-dependencies 会让 Composer 同时更新该包**所有层级的依赖**（不只是直接依赖），但它不会更新无关包。这个选项适合解决因子依赖版本冲突导致的更新失败。
- ✅ 场景举例：更新
laravel/framework时提示illuminate/support v9.x requires php ^8.0，但本地 PHP 是 8.1 —— 加上该 flag 可能连带升级illuminate/support到兼容版 - ⚠️ 风险：它可能把某些间接依赖推到新主版本（如从 v3 → v4），引发兼容性问题，建议先在测试环境验证
- ? 实际命令：
composer update laravel/framework --with-all-dependencies
composer show 和 composer.json 里的约束写法，比反复试命令更省时间。 
