必须用 composer require 的情况是本地开发引入新库时，它会自动更新 composer.json 和 composer.lock，确保版本精确一致；手动修改 composer.json 后运行 install 不会更新 lock 文件，导致环境不一致。
开发中加新包用 composer require，部署或协作时用 composer install——混用会导致 lock 文件被悄悄改写、环境不一致。
什么时候必须用 composer require
你正在本地写代码，需要引入一个新库（比如日志、测试工具、静态分析），就该用它。
- 它会自动把包写进
composer.json的require或require-dev字段，并立即下载安装 - 同时更新
composer.lock，记录精确版本号，保证团队其他人install时拿到一模一样的依赖 - 别手动改
composer.json再跑install：那样不会更新lock，别人拉代码后可能装错版本 - 加开发依赖要显式加
--dev，例如：composer require --dev phpunit/phpunit，否则它会被当成生产依赖塞进require
为什么 composer install 不能用来“加依赖”
install 的唯一职责是「按 composer.lock 还原依赖」，它根本不读取你新加的 require 行——哪怕你手改了 composer.json，它也只会装 lock 里已有的东西。
- 常见错误：改完
composer.json就跑install，结果 vendor 里没出现新包，还误以为命令失效 - 更危险的是：有人在 CI 脚本里写
composer install前删掉了composer.lock，这时它会退化成update行为，拉来一堆未验证的新版包 - 首次克隆项目时才该无脑
install；后续所有“加/删/改依赖”的操作，都该由require或remove触发
composer install 在上线部署时的关键约束
线上环境必须加 --no-dev，否则 require-dev 里的包（比如 phpstan、pest）也会被装上，带来体积膨胀和 autoload 冲突风险。
-
composer install --no-dev不仅跳过安装，还会忽略autoload-dev配置，避免生产环境意外加载 dev 类 - CI/CD 脚本里如果漏了这个参数，轻则多打几十 MB 镜像，重则因
symfony/var-dumper这类 dev 工具被误引用而报Class not found - 注意：
--no-dev对require没影响，生产依赖照常装；它只管require-dev和相关 autoloader
最容易被忽略的一点：团队里只要有一人执行了 composer update 并提交了新的 composer.lock，所有人再 install 就会同步到那个“未经共识”的版本——问题往往不是命令用错，而是没意识到 lock 文件本身已是契约。
