精准更新指定包应使用 composer update vendor/package-name，它只更新目标包及其满足约束的子依赖，不修改 composer.json，行为可控且可预测。
用 composer update 加包名精准更新
直接运行 composer update vendor/package-name 即可只更新指定包，Composer 会跳过其他依赖，只拉取该包及其兼容版本（受 composer.json 中版本约束限制）。
例如想更新 monolog/monolog 到符合 "^2.0" 的最新小版本：
composer update monolog/monolog
注意：这里不加 v 前缀，也不写分支名（如 main），只写标准的 vendor/name 格式。
- 多个包可空格分隔：
composer update guzzlehttp/guzzle symfony/http-foundation - 如果包名拼错或不存在，会报错
Package "xxx" not found - 它仍会检查并更新该包的子依赖（transitive dependencies），但仅限于满足当前
composer.lock和composer.json约束的最小必要范围
为什么不用 composer require --update-with-dependencies？
composer require 默认是「安装+更新」动作，加 --update-with-dependencies 会强制刷新整个依赖图谱，容易意外升级其他包——这不是“只更新单个”的本意。
真正安全的做法是避免触发 require 的隐式更新逻辑。如果你只是想升一个已安装的包，update 是唯一语义明确、行为可控的命令。
-
composer require monolog/monolog:^3.0会改写composer.json并更新整棵树，风险高 -
composer update monolog/monolog不修改composer.json，只按现有约束升级，更可预测 - 若需同时升级包并锁定新版本号，应先手动改
composer.json，再执行composer update
更新失败常见原因和绕过方式
执行 composer update vendor/package 报错，通常不是命令本身问题，而是约束冲突或网络策略导致。
- 版本无可用解：提示
Could not find package ... in a version matching ...→ 检查composer.json中该包的版本约束是否过于严格（如写死"1.2.3"），临时放宽为"^1.2"再试 - 平台要求不满足：如包需要 PHP 8.2，而本地是 PHP 8.1 → 查看错误中
Your requirements could not be resolved后的具体不兼容项 - 私有仓库未配置：报
Could not parse version constraint或 401 → 确认auth.json已配置 token，且仓库地址在repositories中声明 - 想跳过平台检查（仅测试用）：
composer update vendor/package --ignore-platform-reqs，但上线前务必移除
更新后必须检查 composer.lock 变更
composer update 一定会修改 composer.lock，哪怕只动了一个包。忽略这个文件的 diff，等于放弃依赖一致性保障。
- Git 提交前，用
git diff composer.lock确认只有预期包的version、source、dist字段变化 - 如果看到大量其他包哈希变更，说明该包的子依赖被连带升级了——这正常，但需确认是否影响功能
- CI/CD 流程中，应校验
composer.lock是否与composer install结果一致，否则部署可能出错
最易被忽略的是：有人更新完没提交 composer.lock，导致团队其他人 composer install 装的仍是旧版本——这会让“只更新一个包”变成“只在你机器上更新了一个包”。
