composer require会更新composer.json的require字段、拉取兼容版本、递归安装子依赖、刷新autoload.php并写入composer.lock；默认装最新稳定版，但线上推荐用^2.9等约束锁定范围，避免意外升级。
别再手动下载、解压、复制 vendor 里的文件了——composer require 才是 PHP 项目引入第三方包的正确起点，它自动处理依赖解析、版本对齐、自动加载注册，还能避免 class not found 或 cannot declare class 这类典型冲突。
require 命令到底做了什么？
执行 composer require foo/bar 不只是把包下载到 vendor/，它会：更新 composer.json 的 require 字段、拉取兼容版本、递归安装所有子依赖、生成或刷新 vendor/autoload.php、写入精确版本到 composer.lock。
常见误操作：
- 直接改 composer.json 后不运行 composer install → 自动加载没注册，new Foo\Bar() 报错
- 在已有 composer.lock 的项目里只用 require 却不提交 lock 文件 → 团队环境版本不一致
- 用 --dev 装了测试工具（如 phpunit/phpunit），却在生产环境跑了 composer install --no-dev → 测试类不可用但没报错，调试时才暴露
如何选对版本约束？
默认 composer require monolog/monolog 装最新稳定版，但多数线上项目需要锁定范围。版本写法直接影响后续升级成本和兼容性：
-
^2.9：允许 2.9.x 到 2.x 最高兼容版（推荐用于主依赖） -
~2.9.0：等价于>=2.9.0 ，适合需严格控制次版本的场景 -
2.9.*：仅允许补丁更新，但 Composer 官方不推荐，易被误解为通配符 -
dev-main或dev-develop：直接装开发分支，跳过稳定性检查，CI 构建可能失败
注意：composer require foo/bar:dev-main 会把 "foo/bar": "dev-main" 写进 composer.json，下次 composer update 可能拉到不兼容变更 —— 除非你明确需要追踪上游开发进度。
require 失败的三个高频原因
不是网络问题，多数卡在配置或权限上：
- PHP 版本不匹配：目标包声明
"php": "^8.1"，而本地是 7.4 → 看composer show foo/bar的requires字段，或查 packagist 页面的 “Supported PHP versions” - 扩展缺失：比如装
ext-gd相关包却没启用 GD 扩展 → 运行php -m | grep gd确认，Ubuntu 用户常漏装php-gd包 - 私有仓库未配置：公司内部包用
https://packages.example.com，但没在composer.json的repositories里声明 → 错误信息通常是Could not find package foo/internal at any version
临时绕过稳定性检查（不推荐长期用）：composer require foo/bar --stability=dev --prefer-source，但会跳过安全警告，且源码模式体积大、加载慢。
require 后还要手动干啥？
绝大多数情况下，什么都不用做 —— vendor/autoload.php 已就绪，类可直接 new 或 use。但以下情况需额外动作：
- 包提供命令行工具（如
larastan/larastan的phpstan）→ 检查是否已加入bin目录，或运行vendor/bin/phpstan - 包含服务提供者（Laravel 场景）→ 需手动在
config/app.php的providers数组里添加，require不会自动注册 - 包修改了
autoload规则（如加了files或psr-4新命名空间）→ 必须运行composer dump-autoload，否则新文件不被识别
一个容易被忽略的细节：如果项目根目录存在 composer.lock，而你又用 require 加了新包，记得把它连同更新后的 composer.json 一起提交 —— 否则别人 composer install 时不会装这个包，因为 lock 文件没记录。
