Composer如何理解install和update区别_Composer install与update区别策略

composer install必须读composer.lock，因为它只按锁文件中写死的版本号、哈希值和URL安装，确保本地、CI、线上环境vendor目录完全一致；删锁文件或Git忽略它会导致隐式update、依赖不一致及运行时错误。

composer install 为什么必须读 composer.lock

简单来说，composer install 的核心任务就一个：精准复现一个已经被验证过的依赖环境。它不会去重新解读 composer.json 里那些带波浪号或插入符的版本约束（比如 "monolog/monolog": "^3.0"），而是完全信任并遵循 composer.lock 文件里白纸黑字写好的版本号、文件哈希值和下载地址。这么做的目的很明确：确保从你的本地开发机，到持续集成（CI）服务器，再到最终的生产环境，安装出来的 vendor 目录在二进制层面都一模一样。

很多依赖冲突的“玄学”问题，其实都源于对锁文件的错误处理。看看下面这些典型场景：

• 有人觉得锁文件碍事，删掉后直接运行 composer install，结果装出了一堆意料之外的新版本包。这其实是触发了一次隐性的 update 操作，完全背离了 install 的设计初衷。
• 更常见的是，团队在 .gitignore 里忽略了 composer.lock，导致每位成员在拉取代码后，运行 install 得到的是不同版本的依赖组合。接下来，各种“Class not found”错误，或者因序列化行为差异导致的运行时诡异问题，就会接踵而至。

除了保证一致性，锁文件对安装性能的提升也是立竿见影的。当 composer.lock 存在时，install 过程几乎不需要联网查询，也跳过了复杂的依赖关系求解，直接命中本地缓存，安装速度往往是秒级完成。

composer update 为什么会改 composer.lock 并耗时很久

如果说 install 是“照方抓药”，那 update 就是“重新开方”。它的核心动作是暂时搁置当前的 composer.lock，然后基于 composer.json 的版本约束，重新执行一次完整的、递归的依赖求解——要知道，这可是一个NP-hard级别的复杂计算问题。

这个过程具体会做这几件事：

• 联网访问 Packagist 的 API，查询每个依赖包在约束条件下所有可用的最新版本。
• 递归地校验这些版本之间，以及它们与当前 PHP 版本、已安装扩展之间的兼容性，解决可能出现的冲突。
• 最终，生成一套全新的、确定的依赖组合方案，并将每个包的精确版本信息写回 composer.lock 文件。

正因为步骤如此繁复，update 耗时很久也就不足为奇了。一个只有50个包的中等规模项目，卡上一两分钟是常有的事。如果项目配置了 config.platform.php 来锁定 PHP 版本，而你又升级了系统 PHP，那么 update 很可能会因为版本不匹配而直接失败。

所以，使用 update 时必须格外谨慎，有几个信号和技巧需要牢记：

• 先加 --dry-run 参数预览变动：composer update --dry-run，看看哪些包会被升级或降级。
• 升级单个包时，用 --with-dependencies 控制影响范围：composer update phpunit/phpunit --with-dependencies，避免牵一发而动全身。
• 最重要的一条：永远不要在未经过充分测试的分支上，或者直接在生产服务器上运行 composer update，这无异于一场反赌。

什么时候该用 install，什么时候非得用 update

选择 install 还是 update，并非个人习惯问题，而是由不同环境的职责所决定的刚性规则。

• 新成员加入时：克隆项目后的第一件事，必须是 composer install，而不是 update。否则，他本地安装的 symfony/http-kernel 可能比你用的高一个小版本，而那个小版本或许就悄悄修改了 Request 对象的构造逻辑，导致团队间的行为不一致。
• 在自动化流程中：如果在 CI/CD 流水线、Docker 构建脚本或线上部署脚本里出现了 composer update，就等于将项目的版本控制权交给了网络延迟和 Packagist 镜像的同步状态。很多在凌晨突然响起的部署告警，根源往往就在这里。
• 合理使用 update 的场景，其实只有三种：
  – 项目初始化，还没有生成 composer.lock 文件时。
  – 明确需要升级某一个或几个特定的包，例如为了修复某个紧急的安全漏洞（CVE）。
  – 当 composer.json 文件被修改后（比如新增了一个 require 项），并且你确认需要重新计算整个依赖树。

这里有个关键点需要额外强调：修改了 composer.json 之后，如果只运行 composer install 是无效的，它不会感知到你的变更。原因很简单：install 根本不读取 composer.json 里的版本约束字段。

生产环境部署必须加 --no-dev，但别以为加了就安全

composer install --no-dev 几乎是生产环境部署的标配命令。它的作用是跳过 require-dev 部分定义的开发依赖（比如测试框架 phpunit、静态分析工具 phpstan 等），从而减小 vendor 目录的体积，并加快安装速度。但必须理解，这个参数并不改变 install 的根本逻辑：它依然是严格依据 composer.lock 来安装，只是安装时过滤掉了标记为 dev 的包。

有几个容易被忽略但至关重要的细节：

• --no-dev 参数对 composer update 同样生效，但 update 仍然会重新计算所有依赖（包括那些 dev 包的约束），只是最终不安装它们。所以，绝对不能用 update --no-dev 来替代 install --no-dev 进行部署。
• 如果 composer.lock 里记录的某个生产包，在运行时隐式依赖了某个 dev 包（例如通过 class_alias 或反射机制调用），那么使用 --no-dev 安装后，可能会导致运行时错误。这种问题非常隐蔽，往往在部署上线后才暴露出来。
• 在 CI 环境中构建时，通常还会加上 --prefer-dist（优先下载压缩包）和 --no-interaction（非交互模式）参数，以避免因下载源码或等待命令行交互而拖慢整个流程。

说到底，最稳健的部署链路其实非常清晰：在开发环境通过可控的 update 更新依赖并提交新的 composer.lock 到代码库，然后在生产服务器上，坚定不移地只执行 composer install --no-dev --prefer-dist。任何偏离此路径的变体，都在无形中为系统引入了不必要的风险变量。