唯一可靠方式是执行composer update vendor/package-name，如composer update monolog/monolog；它仅按composer.json约束更新该包及其直系依赖，不改动其他顶层包，避免全量更新引发的BC break。
唯一可靠方式是执行 composer update vendor/package-name，比如 composer update monolog/monolog。其他写法大概率会全量更新、静默失败，或触发非预期依赖重算。
为什么 composer update monolog/monolog 才是正解
无参数的 composer update 会重新解析整个 composer.json，升级所有满足约束的包，极易引发 BC break；而指定包名后，Composer 行为是确定的：
- 只按
composer.json中该包的版本约束（如"^2.8"）拉取最新兼容版（比如2.10.0） - 仅顺带升级它**直接依赖**、且未被其他包锁死的子依赖（例如
psr/log若需升到^2.0才能装monolog 2.10，就会升） - 不会碰
laravel/framework、guzzlehttp/guzzle等其他顶层包，哪怕它们也在composer.json里 - 修改后的版本会写入
composer.lock，但只改对应条目
composer update 常见误写和后果
这些写法看着像，实际效果完全不同：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer update monolog（漏掉/monolog）→ Composer 找不到匹配项，静默 fallback 到全量更新 -
composer update "monolog/monolog"（加引号）→ 某些 shell 会把它当字符串忽略，等效于无参数执行 -
composer require monolog/monolog --update-with-dependencies→ 强制重算整个依赖图，不是“更新已有包”，而是假装新增再安装，容易带入非预期变更 -
composer update（不带任何参数）→ 全量更新，不是“部分更新”
更新后发现别的包也变了，正常吗
正常，只要变化的是目标包的**直系依赖**，且旧版本无法满足新版本的 require 声明，Composer 就必须升级它。
- 例如
monolog/monolog:^3.0的composer.json明确声明"symfony/console": "^6.2"，而你lock里是6.1，那它必须升——否则依赖图不合法 - 这种连带升级无法用开关禁掉，它是语义化版本 + 依赖求解的必然结果
- 想预判影响范围：执行
composer show monolog/monolog查它的require列表；或先加--dry-run：composer update monolog/monolog --dry-run - 确认是否真只动了目标包：执行
git diff composer.lock，只应出现packages下对应包名的version、source、dist字段变化
想升到特定版本，但 composer update vendor/package:3.0.0 报错
Composer 不支持命令行直接指定版本更新（该语法无效）。要锁定版本，必须两步走：
- 手动编辑
composer.json，把对应包的版本字段改成目标值，例如："monolog/monolog": "3.0.0" - 再执行
composer update monolog/monolog或composer update（此时只会影响该包，因其他包约束未变）
注意：如果该包在 require-dev 中，记得加 --dev；大小写敏感，Monolog/monolog 或 monolog/Monolog 都会失败；composer.lock 文件损坏或平台配置（如 platform.php）与当前环境不一致，也可能导致看似成功却无实际变更。
