执行 composer update monolog/monolog 仅更新该包及其满足约束的直接依赖，最安全；加 --with-all-dependencies 会递归升级所有层级依赖，需慎用。
composer update 后面直接跟包名就能只更新那个包
想只更新 monolog/monolog，执行 composer update monolog/monolog 就行。Composer 会跳过其他所有包，仅拉取该包及其依赖的兼容版本（受 composer.json 中 require 版本约束和 composer.lock 现有锁定影响）。
常见错误是加了 --with-dependencies 却没意识到它会连带升级间接依赖——比如更新 laravel/framework 时带上这个参数，可能顺手把 symfony/http-foundation 也升到新主版本，引发兼容问题。
- 不加任何参数：只更新目标包本身（及其满足当前约束的子依赖），最安全
- 加
--with-all-dependencies：递归更新目标包所有层级的依赖（含 dev 依赖），慎用 - 加
--no-update没意义——这会让update命令变成空操作
为什么有时指定包名却没更新？检查三个地方
执行 composer update vendor/package 后版本没变，大概率卡在这三处：
-
composer.json里该包的版本约束太紧，比如写死"vendor/package": "1.2.3"，而 1.2.3 已是最新，自然不动 -
composer.lock已锁定更高版本（比如你之前手动改过 lock 文件或用了composer require vendor/package:dev-main），但require字段没同步，导致 update 按旧约束走 - 包已通过
replace或provide被其他包替代（少见但真实存在），Composer 认为“无需安装”
快速验证方法：运行 composer show vendor/package 看当前装的版本和可用版本范围；再对比 composer.json 的 require 行和 composer.lock 里对应条目。
想强制重装某个包（不管版本是否变化）
用 composer reinstall（Composer 2.2+ 内置）最直接：composer reinstall vendor/package。它会先卸载再按当前 composer.json 约束重新安装，绕过版本比较逻辑。
老版本 Composer 没这个命令，得手动组合：composer remove vendor/package && composer require vendor/package。注意 require 不带版本号时会按 composer.json 原约束装，带版本号则会覆盖原约束（比如原是 ^2.0，你写 composer require vendor/package:3.0，composer.json 就会被改成 "3.0"）。
别用 composer update --lock 试图“骗过”更新逻辑——它只重写 lock 文件，不碰 vendor 目录，实际没重装。
更新单个包时 dev 依赖会不会动？
默认不会。composer update vendor/package 只处理 require 和 require-dev 中显式声明的该包，但不会主动升级其 require-dev 里的依赖（那些属于开发时的工具链，和运行时无关）。
除非你额外加 --with-all-dependencies 或 --with-dependencies，否则像 phpunit/phpunit 这类只在目标包的 require-dev 里出现的包，完全不受影响。
一个容易被忽略的点：如果目标包自身是 require-dev 里的（比如你只在开发环境需要它），那必须加 --dev 参数，否则 Composer 默认只扫 require 区域——composer update vendor/package --dev 才生效。
