composer require vendor/package 默认只添加目标包并更新其直接依赖，不重算全局依赖图；它先写入 composer.json 的 require 段，再局部解析该包及其子依赖，仅当子依赖未被其他顶层包共用或锁死时才更新，否则保持原版本不变。
直接用 composer require vendor/package 就行，它默认不重算整个依赖图，只添加目标包并更新其直接依赖；误加 --update-with-dependencies 或运行 composer update 后续操作才会连带升级其他包。
为什么 composer require 通常不会动其他包
该命令本质是两步：先写入 composer.json 的 require 段，再执行一次局部 update —— 但这个局部更新只围绕新加入的包及其声明的子依赖展开。只要这些子依赖没在项目中被其他顶层包共用，就不会波及已有包版本。
- 比如你当前装着
monolog/monologv2.9.1 和guzzlehttp/guzzlev7.4.5，运行composer require spatie/laravel-permission，Composer 只会检查spatie/laravel-permission所需的illuminate/support版本，而不会去动monolog或guzzle - 如果新包依赖的某个子包（如
psr/log）已被其他包锁死在 v1.1.4，且新包兼容该版本，Composer 就不会升级它 -
require不会修改未涉及的require-dev包，比如phpunit/phpunit、laravel/pint都保持原样
哪些操作会意外触发其他包更新
看似在“加包”，实则悄悄重算全局依赖，常见于以下情况：
- 执行
composer require vendor/package --update-with-dependencies—— 这个参数根本不存在，但有人误输后 Composer 会静默忽略并 fallback 到完整update，导致所有包升级 - 在
require前刚手动改过composer.json里的其他约束（比如把"php": "^8.1"改成"^8.2"），require会一并响应这个变更 - 目标包本身要求更高版本的 PHP 或扩展（如强制要
ext-pdo_pgsql），而你的环境不满足，Composer 可能回退到旧版兼容包，间接影响其他依赖选择 - 运行
composer require后立刻跟一句composer update（比如 CI 脚本里漏删了），等于白做了隔离
如何验证 require 没乱动其他包
执行完 composer require 后，别急着提交，先看三处：
- 运行
git diff composer.lock：只应出现新增包及其子依赖的条目，packages数组里不该有monolog/monolog、symfony/console等已有包的版本变动 - 执行
composer show --outdated：输出里不应冒出一堆新提示，尤其注意主版本跳变（如2.9.0 → 3.0.0） - 检查
vendor/目录修改时间：用ls -lt vendor/ | head -5（Linux/macOS）或dir /o:d vendor（Windows），确认只有新包目录和极少数子依赖目录被更新，而非整个vendor/时间戳全刷新
最易被忽略的是：composer require 成功后，composer.lock 里可能悄悄更新了 platform 字段（比如 PHP 版本号），这会导致下次 install 在低版本环境失败——务必检查 lock 文件顶部的 platform 区块是否被改写。
