在开发过程中，Composer的require与install命令有何具体应用场景区别？

本文共计727个文字，预计阅读时间需要3分钟。

在开发过程中添加新包时，使用以下命令：

什么时候必须用 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 文件本身已是契约。