composer require 是最安全、最标准的引入方式，它自动更新 composer.json、生成 composer.lock 并安装包，避免手动出错，且默认使用稳定版约束，支持最小兼容升级与精准验证。
直接说结论：用 composer require 是最安全、最标准的引入方式，但必须在项目根目录下执行，且不能跳过 composer.json 的自动更新。
为什么 composer require 比手动改 composer.json 更可靠
手动编辑 composer.json 后忘记运行 composer install，或版本号写错（比如漏掉 ^ 或写成 ~），极易导致依赖不一致或安装失败。而 composer require 会自动完成三件事：更新 composer.json、写入锁文件 composer.lock、下载并安装包——中间任何一步失败都会中止，不会留下半残状态。
- 它默认使用稳定版（
^约束），避免意外拉取dev-分支 - 如果当前已存在
composer.lock，它会基于该锁文件做最小兼容升级，而不是重算整个依赖树 - 执行后可立刻用
composer show验证是否真装上了，比翻vendor/目录快得多
composer require 常见错误现象和对应操作
典型报错如 Could not find package xxx at any version，往往不是包不存在，而是拼写、大小写或仓库源配置问题。
- 包名写错：比如想装 Laravel 的缓存驱动，输成
composer require illuminate/cache是对的，但写成illuminate-cache（用了短横线）就会失败 - 没切对源：国内用户常配了阿里云镜像，但某些私有包只在 packagist.org 上，此时需临时加
-d composer.repo.packagist.org或先composer config -g repo.packagist composer https://packagist.org - PHP 版本不匹配：报错含
requires php ^8.1但本地是 8.0，就得升级 PHP 或加--ignore-platform-reqs（仅开发环境临时用，上线前必须解决）
带版本号和选项的实操建议
不指定版本时，composer require 默认装最新稳定版；但线上项目强烈建议显式锁定范围，避免下次 composer update 意外升级。
- 装指定版本：
composer require monolog/monolog:^2.9（推荐用^，兼容小版本更新） - 只装开发依赖：
composer require --dev phpunit/phpunit，这样不会打进生产包 - 跳过自动加载优化（调试 autoload 问题时）：
composer require --no-autoloader，之后再手动跑composer dump-autoload - 强制重装已有包（比如怀疑 vendor 损坏）：
composer require --update-with-dependencies vendor/package
容易被忽略的细节：require 后的自动加载不是立即生效
哪怕 vendor/autoload.php 已存在，新增类也不会被识别，除非重新生成自动加载映射。这不是 bug，是 Composer 的设计逻辑——autoload 信息来自 composer.json 和 composer.lock，不是实时扫描 vendor/。
- 绝大多数情况，
composer require会自动触发dump-autoload，但如果你加了--no-autoloader或之前禁用了该行为，就得手动补一句composer dump-autoload - 如果类放在非标准命名空间（比如没遵循 PSR-4），光靠
require不够，还得在composer.json的autoload字段里手动加映射 - 修改了
autoload配置后，composer require不会自动重刷映射，必须单独跑composer dump-autoload
真正卡住人的，往往不是命令本身，而是它背后那一层 autoload 生成机制和 lock 文件的约束逻辑。多看一眼 composer show 输出和 vendor/composer/autoload_psr4.php 里的实际映射，比反复重装快得多。
