是，composer update vendor/package-name 默认会递归更新其所有满足约束的依赖；要最小化变更，需手动锁定关键依赖版本或用 composer install 配合精确的 composer.lock。
composer update 只更新一个包会连带升级依赖吗
会，但可以控制。默认 composer update vendor/package-name 不仅更新目标包，还会递归更新它所有满足版本约束的依赖（包括间接依赖）。这不是 bug，是 Composer 的依赖求解机制决定的——它要保证整个 lock 文件里所有包的版本组合依然满足所有 composer.json 中的约束。
常见错误现象：composer update monolog/monolog 后，symfony/console 也升了小版本，导致命令行工具行为异常。
- 想最小化变更？加
--with-dependencies是默认行为，不加也一样；真要禁用依赖升级，得用--with-all-dependencies的反向操作——其实没有直接开关，只能靠锁死依赖版本 - 更稳妥的做法：先运行
composer show vendor/package-name看当前依赖树，再决定是否手动在composer.json中固定关键依赖的版本（如"symfony/console": "^5.4"） - 如果目标包本身依赖宽松（比如
"php": "^7.4 || ^8.0"），而你的环境是 PHP 8.2，Composer 可能顺手把其他兼容 PHP 8.2 的包也拉高——这属于隐式兼容性推动，不是误操作
composer require --update-with-dependencies 和普通 update 的区别
这个命令根本不存在。composer require 没有 --update-with-dependencies 参数，文档和源码里都搜不到。用户常从过时博客或错误补全里看到它，一试就报错：[InvalidArgumentException] Unknown option: --update-with-dependencies。
真实可用的、最接近意图的替代是：
-
composer require vendor/package-name:^3.0 --no-update先写入composer.json但不执行安装，之后手动composer update vendor/package-name，这样能避免意外触发全量更新 - 如果只是想升级已有包到最新兼容版，
composer update vendor/package-name就够了；想强制忽略composer.lock重算全部依赖，才需要--lock或删 lock 文件（不推荐） - 注意
require默认会执行 install，所以直接composer require vendor/package-name在已存在该包时，等价于update+ 可能的依赖追加——行为比想象中更重
怎么确保只改一个包、其他全不动
唯一可靠方式：用 composer install 配合精确的 composer.lock。前提是 lock 文件里已经存有你想要的目标包版本，且没被其他操作污染。
实操路径：
- 先查清目标版本：
composer show -p vendor/package-name看可用版本列表，挑一个明确语义的（比如2.9.2，而不是^2.9） - 手动编辑
composer.json，把该包的版本号写死："vendor/package-name": "2.9.2"（双引号不能少，否则 JSON 解析失败） - 删掉
composer.lock，再跑composer install——这时只会装 lock 里记录的那套组合，不会重新求解；但更安全的做法是保留 lock，只改 json 后运行composer update vendor/package-name --with-all-dependencies，它会尽量复用现有依赖版本 - 验证是否“真没动别的”：
git diff composer.lock，重点看除了 target 包外，是否还有其他条目变动；如果有，说明它的某个子依赖在新版本里声明了更宽的依赖范围
更新单个包后 vendor/autoload.php 失效或类找不到
大概率是 autoloader 没刷新，不是包本身问题。Composer 的自动加载映射（autoload）是生成出来的，不是实时解析的。
必须做的一步：composer dump-autoload。尤其当包里新增了命名空间、修改了 psr-4 映射，或你刚手动改过 composer.json 的 autoload 字段。
- 常见错误：更新完包就直接跑 PHP 脚本，报
Class not found，其实文件都在 vendor 里，只是 autoloader 缓存没更新 - 如果用了优化模式（
composer install --optimize-autoloader），更新单个包后也得重新 dump，否则classmap不包含新文件 - 某些包（比如 Laravel 的 service provider）还依赖配置文件或缓存（如
config:cache），光 dump autoloader 不够，得按框架要求额外清理
复杂点在于：包升级可能同时带来接口变更、废弃方法、甚至目录结构调整——这些不会被 autoloader 报错，但会在运行时炸。别只盯着文件是否存在，得看它实际怎么被调用。
