composer update vendor/package-name是唯一可靠方式，必须用完整包名（如monolog/monolog），漏/、加引号、不带包名或误用--only均会导致报错、静默跳过或全量更新；它按composer.json约束更新该包及其直系依赖，其他顶层包不变。
composer update vendor/package-name 是唯一可靠方式，漏掉 /、加引号或不带包名都会失控。
必须用完整包名，且不能加引号
比如要升级 monolog/monolog，命令必须是：
composer update monolog/monolog
以下写法全错：
-
composer update monolog→ 报错Package "monolog" not found -
composer update "monolog/monolog"→ shell 可能忽略参数，退化为无参update，触发全量重装 -
composer update --only monolog/monolog→Unrecognized option: --only，Composer 根本不支持
包名拼错（如 monolog/monolg）也不会报错，而是静默跳过——得靠 composer show monolog/monolog 确认是否真装着这个包。
为什么其他包也变了？这不是 bug
composer update monolog/monolog 会连带升级它的直系依赖，只要这些依赖版本不满足新包的 require 声明。例如：
- 当前
psr/log是1.1.4，但monolog/monolog:^3.0要求^2.0 - Composer 就必须升
psr/log，否则无法安装monolog新版
这种连带升级无法禁用，它是语义化版本 + 依赖求解的必然结果。想预判影响范围，先运行：
composer show monolog/monolog | grep requires
再对比 composer.lock 里对应依赖的当前版本。
想真正“只动一个包”，得提前锁死子依赖
如果不想让 psr/log 或 symfony/console 被推高，最稳妥的做法是在 composer.json 中显式固定它们的版本：
"psr/log": "^1.1", "symfony/console": "^5.4"
然后再执行 composer update monolog/monolog。升级后立刻验证：
composer show psr/log
确保输出仍是 1.1.x 版本。注意：如果其他顶层包（如 laravel/framework）也 require 同一子依赖，且约束更严，Composer 仍可能被迫升级——这时得看 composer why-not psr/log:^1.1 查冲突源。
别信 --dry-run 能代替测试
composer update monolog/monolog --dry-run -n 能看到将动哪些包，但它不校验运行时兼容性。常见翻车点：
- 输出里出现
downgrading或removing→ 很可能有 BC break - CI 脚本里用
--dry-run判断“要不要执行” → 不可靠，它不反映实际安装后行为 - 没配
config.allow-plugins白名单 → 某些插件（如phpstan/extension-installer）会在update时自动激活，触发额外安装逻辑
真正安全的流程是：开分支 → --dry-run 预览 → 手动检查变更项 → 运行完整测试 → 再合入。锁文件变动本身不危险，危险的是你没看见的运行时副作用。
