composer require 默认修改 composer.json 并立即安装，需确保在项目根目录执行；版本约束推荐 ^2.10，避免写死或跨主版本；类无法加载时检查 autoload 配置并运行 dump-autoload；部署前确认 composer.lock 已更新且 CI/CD 执行了 composer install --no-dev。
直接运行 composer require 就能安装第三方库，但多数人卡在版本冲突、自动加载失效或 dev 依赖误入生产环境上。
require 命令的基本用法和常见错误
composer require 默认修改 composer.json 并立即安装，不是只写配置。如果执行后没生成 vendor/ 或类找不到，大概率是没触发安装，或者当前目录不是项目根目录。
- 正确姿势：
composer require monolog/monolog:^2.10
（会同时写入require字段并执行install） - 加
--dev安装到require-dev：composer require --dev phpunit/phpunit:^10
- 禁止自动安装（仅更新
composer.json）：加--no-install，后续需手动composer install - 错误示例：
composer require "foo/bar"不带版本号 → Composer 会尝试猜最新稳定版，但可能选到不兼容的主版本（如 v3 而非 v2）
版本约束写错导致依赖冲突
写死版本（如 "1.2.3"）看似稳妥，实则阻碍后续更新；用 ^ 却忽略主版本语义，比如 ^1.9 允许升级到 1.10，但 ^2.0 不会降级兼容 1.x。
- 推荐写法：
^2.10（允许2.10.0到2.999.999，不跨主版本） - 要锁定小版本兼容性（如仅允许
2.10.x）：用~2.10.0 - 查看包真实可用版本：
composer show monolog/monolog --all
- 冲突时别硬删
vendor/和composer.lock—— 先用composer why-not vendor/package:version
查谁在阻止安装
require 后类无法自动加载？检查 autoload 配置
不是所有包都开箱即用。有些库（尤其老项目或私有包）没配 autoload，或用了 psr-4 但命名空间与目录结构不匹配。
- 确认包自身是否声明了 autoload：查看其
composer.json中的autoload字段 - 若你引入的是无 autoload 的工具类库（如纯函数库），需手动加加载逻辑，或在你项目的
composer.json中补："autoload": { "files": ["vendor/foo/bar/helpers.php"] }然后运行composer dump-autoload - 修改自己项目的 autoload 后，必须执行
composer dump-autoload，否则新规则不生效
最常被跳过的一步：执行 composer require 后，别忘了检查 composer.lock 是否更新，以及 CI/CD 流程里是否仍用旧 lock 文件部署 —— 本地能跑，线上报 Class not found，八成是 lock 文件没提交或部署脚本跳过了 composer install --no-dev。
