composer require vendor/package 默认只添加目标包并更新其直接依赖，不重算全局依赖图；它先写入 composer.json 的 require 段，再局部解析该包及其子依赖，仅当子依赖未被其他顶层包共用或锁死时才更新，否则保持原版本不变。

直接用 composer require vendor/package 就行，它默认不重算整个依赖图，只添加目标包并更新其直接依赖；误加 --update-with-dependencies 或运行 composer update 后续操作才会连带升级其他包。

为什么 composer require 通常不会动其他包

该命令本质是两步：先写入 composer.json 的 require 段，再执行一次局部 update —— 但这个局部更新只围绕新加入的包及其声明的子依赖展开。只要这些子依赖没在项目中被其他顶层包共用，就不会波及已有包版本。

• 比如你当前装着 monolog/monolog v2.9.1 和 guzzlehttp/guzzle v7.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 都保持原样

哪些操作会意外触发其他包更新

看似在“加包”，实则悄悄重算全局依赖，常见于以下情况：

Academic Composer Upload

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

下载

• 执行 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 区块是否被改写。