Composer require与install命令的核心区别

Composer require与install命令的核心区别

简单来说，composer install 的核心任务就一个：严格按 composer.lock 文件还原依赖。它不读取 composer.json 里的新约束，也绝不更新 lock 文件本身。这个命令下载、解压、写入 vendor 目录的每一个包，其版本号都精确锁定在 lock 文件记录的那一刻。可以说，它是保障 CI/CD 和生产环境绝对一致性的最后一道防线。

composer install 只还原，不修改依赖声明

这个命令的逻辑非常“固执”：它眼里只有 composer.lock。哪怕你刚刚在 composer.json 里兴奋地加了一行 "foo/bar": "^1.0"，只要 composer.lock 文件还存在且格式合法，composer install 就会完全无视那行新增内容。它的工作不是“安装当前声明”，而是“精确还原上次锁定的状态”。

这里有几个常见的理解误区，值得特别注意：

• 如果你发现执行 composer install 后，composer.lock 文件的时间戳变了，甚至内容有增删，那可不是它在“更新”。实际情况往往是 lock 文件与 composer.json 已经不兼容（比如你在 JSON 里删除了某个包，但没同步清理 lock 文件），Composer 正在被迫进行“修复”，而不是执行常规的安装。
• 在 CI/CD 流水线中，如果漏掉了 --locked 参数，会埋下一个隐患：一旦 lock 文件缺失或格式异常，命令会悄悄地回退到按 composer.json 重新生成 lock 文件。这直接导致了环境依赖的“漂移”，破坏了部署的一致性。所以，部署脚本里必须明确写成：composer install --locked。原则就是，宁可失败报错，也绝不允许命令自作主张。

composer require 是“改声明 + 局部重算”

与 install 的“保守”不同，composer require 是个积极的“建设者”。它一口气干两件事：首先，往 composer.json 的 require 或 require-dev 字段里追加一行新依赖声明；紧接着，它会立即执行一次等效于 composer update [新包名] 的操作——也就是只重新计算这个新包及其直接子依赖的版本，更新 composer.lock 文件，并最终安装到 vendor 目录。

它的使用场景因此非常明确：

• 开发中引入新库：比如需要添加日志组件或 HTTP 客户端。
• 升级单个包：命令 composer require monolog/monolog:^3.0 的效果，等同于先手动修改 JSON 文件，再执行针对该包的 update 操作。
• 需要注意的是，它不能用于批量安装。不存在 composer require a/b c/d e/f 这样的语法。如果想批量添加多个包，比较规范的做法是使用 --no-update 参数多次执行 require 命令，将声明先写入 JSON，最后再统一执行一次 composer update --no-interaction 来完成安装。

为什么不能用 install 替代 require 来加新包

原因就在于上面强调的逻辑：composer install 根本不解析 composer.json 的变更。你手动编辑 JSON 文件加入了新包，然后满怀期待地运行 install，结果它会完全无视你的新增声明，依然按照旧的 lock 文件安装。想让新包真正落地，只有两条路：

• 删掉 composer.lock 文件，再运行 composer install。（危险！） 这会触发全部依赖的重新计算，可能导致大量依赖版本意外升级，破坏稳定性。
• 使用 composer require。（推荐！） 这种方式安全可控，只进行局部更新，并自动同步 lock 文件。

另外有个小细节：composer require 过程中间出现的警告信息（例如 Package xxx is abandoned），其实只发生在它背后触发的 install/update 步骤里。require 命令本身并不会去检查已安装的包是否被废弃——它只关心自己新加入的这个。

容易被忽略的细节：lock 文件的“权威性”边界

composer.lock 的锁定能力是强大的，但并非无所不能。它锁定的核心是“包名、精确版本号、分发源地址和校验码”。然而，它不锁定 PHP 版本、不锁定扩展要求，甚至不锁定 composer.json 里写的 config 配置或 scripts 脚本。

这意味着：

• 你将 PHP 从 8.1 升级到 8.3，然后运行 composer install --locked，命令依然会成功执行。但此时，lock 文件里记录的某个包，可能在运行时与 PHP 8.3 并不兼容。
• composer.json 里的 "replace": {"old/package": "*"} 这类声明，只影响 Composer 解析依赖树时的安装逻辑，它并不提供任何实际的类或功能。别指望它能自动“替代”一个已被废弃的包的运行时行为。

所以说，真正可靠的环境约束，还得依靠 composer.json 里明确的 "php": "^8.1" 版本声明，以及 CI 流程中的显式校验。把环境一致性的希望完全寄托在 lock 文件的完整性上，是不够的。