应使用 composer update vendor/package-name 精准升级单包；默认 composer update 会重建整个依赖图、丢弃 composer.lock，导致不可控变更。
想只更新一个包，别碰其他依赖，就用 composer update vendor/package-name —— 不加引号、不加版本号、不加任何额外参数。
为什么 composer update 默认不是“精准升级”
直接运行 composer update 会丢弃 composer.lock，重新计算整个依赖图，所有包都可能被重装。这不是升级，是重建。你看到的“升了几个小版本”，其实是 Composer 在当前 composer.json 约束下重新选的最新兼容组合，行为不可控。
- 常见错误：CI 流水线里写
composer update，结果每次构建拉的依赖 SHA 不同，线上出问题却查不到原因 - 本地开发误操作后，
git status显示composer.lock大量变动，说明整棵树被重算过 - 真正安全的做法是：CI 一律用
composer install；本地升级只指定包名
composer update monolog/monolog 到底更新了什么
这条命令只影响三类内容：该包自身、它在 composer.json 中显式声明的子依赖（如 "psr/log": "^1.1"）、以及这些子依赖未被其他包锁死的部分。
- 如果
symfony/polyfill-php80同时被laravel/framework和monolog/monolog使用，且laravel/framework锁死^2.0，那即使monolog新版要求^3.0，Composer 也不会升级它——除非你加--with-all-dependencies并解决冲突 - 包名拼错（比如
monolog/monolg）不会报错，命令静默成功但无任何变更，composer show monolog/monolog版本不变 - Linux/macOS 下加引号（
"monolog/monolog"）多数情况能跑通，但某些 shell 或旧版 Composer 会忽略或解析失败，不加最稳
怎么升到特定版本（比如 v3.1.2）
Composer 没有 composer update foo/bar@v3.1.2 这种语法。要锁定版本，必须分两步走：
- 先手动编辑
composer.json，把对应行改成"monolog/monolog": "3.1.2"（无^或~） - 再执行
composer update monolog/monolog，让 Composer 把composer.lock里 version 字段和 source.reference 都对齐到这个精确值 - 改完立刻
git diff composer.json，检查是否多删了^、引号类型是否统一（双引号优先）、逗号有没有漏
注意：composer require monolog/monolog:3.1.2 表面看一样，但它会触发全量依赖重算，可能连带升级 phpunit/phpunit 或修改平台要求，偏离“只动一个包”的目标。
升级失败卡住？先看 composer why-not
执行 composer update monolog/monolog 后版本没变，大概率是约束冲突。不是网络问题，也不是权限问题。
- 典型提示：
Root composer.json requires monolog/monolog ^2.5, found monolog/monolog[dev-main, 3.0.x-dev] but these were not loaded—— 说明你写的^2.5不允许升到 3.x - 快速定位拦路虎：
composer why-not monolog/monolog:3.1.2，输出会明确告诉你哪个包（比如some-old-plugin）硬锁了monolog的版本范围 - 如果
composer.lock里该包的version字段和composer.json不一致，说明上一次 update 没生效，得先确认 lock 文件是否被 git ignore 或误删
复杂点在于：一个包的升级常牵扯至少两级依赖，而 --with-dependencies 和 --with-all-dependencies 的行为差异极容易被忽略——前者只升直系，后者递归升全部，但后者一旦遇到硬冲突就会直接退出，不给你试错机会。
