正确命令是composer update vendor/package-name，无需额外参数；必须写全vendor/name格式，漏vendor、错大小写、包未声明在composer.json中或误加--with-dependencies等均会导致失败。

composer update vendor/package-name 是唯一正解

想只更新一个包，就直接敲 composer update vendor/package-name，别加任何额外参数，也别试图用 composer require 曲线救国。这是 Composer 原生支持的最小扰动方式，不是权宜之计。

常见错误包括：

• 漏写 vendor/ 部分，比如只输 composer update monolog → 报错或静默失败
• 包名大小写错误，Monolog/monolog 或 monolog/Monolog 都不认
• 包根本没出现在 composer.json 的 require 或 require-dev 里 → 报错 Package ... is not required in your composer.json
• 加了 --with-dependencies 或 --only → 后者根本不存在，前者会扩大影响面，违背“单包”初衷

为什么 update 不生效？先查三件事

命令执行后版本没变、没报错、也没反应？大概率是以下其一：

• composer show -l vendor/package-name 看当前装的是不是已满足约束的最新版（比如 "^2.8" 锁着，而 2.10.0 已在 composer.lock 里）
• composer outdated vendor/package-name 确认真有可升级的新版本
• 检查 composer.json 里该包的版本字符串是否太死，比如写成 "2.8.0" 而非 "^2.8" —— 前者不会自动升小版本

如果包在 require-dev 里（如 phpunit/phpunit），必须显式加 --dev： composer update phpunit/phpunit --dev

更新后 composer.lock 变了哪些？怎么看

执行完 composer update vendor/package-name，composer.lock 不可能“只改一行”，但变化范围可控：

Academic Composer Upload

辅助学术写作，包括查找资料、生成大纲、引用扩写及润色风格，同时确保引用规范。

下载

• 目标包自身条目（packages 或 packages-dev 下对应项）的 version、source、dist 字段哈希必然更新
• 它新版本 require 的直连依赖，若当前锁版本不满足，也会被一并更新（例如 monolog/monolog 升到 v3 后 require psr/log ^2.0，而你原来锁的是 ^1.0，就会动）
• 其他所有未被牵连的包，记录完全不动 —— git diff composer.lock 是最靠谱验证方式

如果发现一堆无关包哈希全变了，优先怀疑：platform 配置与本地 PHP 版本/扩展不一致，或误用了 --with-all-dependencies

遇到 “Your requirements could not be resolved” 怎么办

这不是命令错了，是依赖树卡住了。典型场景：你想升 symfony/console，但它要求 symfony/polyfill-php80 ^1.25，而另一个包硬锁了 ^1.20。

• 先跑 composer why-not symfony/polyfill-php80:^1.25，快速定位谁在拦路
• 再用 composer show symfony/console 查它实际兼容哪些子依赖版本
• 不要急着加 --ignore-platform-reqs —— 这会让 composer.lock 生成不一致，CI 构建大概率失败
• 真正安全的做法是：降级那个拦路包（看它有没有新版支持更高依赖），或收紧目标包的版本约束（比如从 ^6.0 改为 ~6.0.10）

复杂点在于：Composer 的“单包更新”本质是局部重解析，不是原子操作。它尊重整个依赖图的约束，所以“只动一个”的前提，是你写的约束本身没和其他包打架。