composer require 是唯一安全方式，它原子化完成写入 composer.json、更新 composer.lock 和安装包三步；手动改 JSON 易出错且不可追溯，易导致版本不匹配或 autoload 失效。
直接用 composer require 就行，但必须在项目根目录下执行，且不能跳过 composer.json 的自动更新——这是唯一安全、可追溯、能被 CI/CD 正确识别的方式。
为什么不能手动改 composer.json 后再 composer install
手动编辑容易漏掉版本约束符号（比如写成 "guzzlehttp/guzzle": "7.0" 而不是 "^7.0"），导致 Composer 拒绝安装（因为没有 exact 7.0.0 这个 release）；更常见的是改完忘记运行 composer install，或者误用 composer update 重算整个依赖树，把其他包也升级了。而 composer require 会原子化完成三件事：写入 composer.json、更新 composer.lock、下载并安装包——任一环节失败，整个操作就中止，不会留下半残状态。
composer require 带版本号的实操要点
不加版本号时，Composer 默认装最新稳定版（带 ^ 约束），但线上项目必须显式指定：
-
composer require guzzlehttp/guzzle:^7.9—— 推荐，允许 7.9.x 补丁更新，不跨主版本 -
composer require monolog/monolog:~2.10.0—— 更窄，只允许 2.10.x 小版本内更新 -
composer require --dev phpunit/phpunit:^10—— 开发依赖进require-dev，部署时可用--no-dev跳过 -
composer require --no-autoloader illuminate/cache—— 临时禁用 autoload 生成（比如调试加载问题），之后需手动composer dump-autoload
装不上？先查这三件事
典型报错 Could not find package xxx at any version 很少是包真不存在，多数是以下原因：
- 包名拼写错误：
illuminate/cache对，illuminate-cache（短横线）错 - 当前镜像源没同步该包：国内用户配了阿里云镜像，但某些新包或私有包只在
packagist.org上，可临时切回官方源composer config -g repo.packagist composer https://packagist.org - PHP 版本不兼容：如
require声明了php ^8.1，但本地是 8.0，此时要么升级 PHP，要么仅开发环境临时加--ignore-platform-reqs（上线前必须删掉）
composer require 后类还是找不到？
这不是 bug，是 Composer 的设计逻辑：新增包的 autoload 信息来自 composer.json 和 composer.lock，不是实时扫描 vendor/。哪怕 vendor/autoload.php 已存在，也必须重新生成映射：
- 执行
composer dump-autoload（尤其当你改过自己项目的autoload配置，比如加了"files"） - 确认
composer.lock文件已提交到 Git——CI/CD 部署时若用旧 lock 文件，composer install --no-dev可能装出和本地不一致的依赖树 - 如果引入的是无 autoload 的纯函数库（比如某个
helpers.php），得在自己项目的composer.json里手动补"autoload": { "files": ["vendor/foo/bar/helpers.php"] }，再跑一次dump-autoload
最常被跳过的动作：执行 composer require 后，不检查 composer.lock 是否更新、不验证 composer show vendor/package 是否真出现在列表里、也不确认 CI 流水线是否用了同一份 lock 文件——这些点一漏，本地能跑，线上就 Class not found。
