composer update 比 install 慢，因其需重新解析依赖、发起大量网络请求、运行复杂版本决策算法并减少缓存利用；而 install 直接按 lock 文件下载已知版本，过程简单高效。
很多人在使用 Composer 时会发现，执行 composer update 明显比 composer install 慢很多。这并不是错觉，而是由两者工作原理的本质区别决定的。下面我们就来深入解析为什么 Composer update 比 install 慢。
1. 依赖解析机制不同
composer install 优先读取项目根目录下的 composer.lock 文件，该文件记录了当前所有依赖包的确切版本。Composer 直接按照 lock 文件列出的版本下载对应包，不需要重新计算依赖关系。
而 composer update 的目标是寻找符合条件的最新版本。它会忽略 composer.lock，重新访问所有配置的镜像源或官方仓库，获取每个依赖及其子依赖的最新可用版本信息，并进行复杂的依赖冲突解决和版本匹配计算。
这个过程涉及大量网络请求和逻辑判断，因此耗时显著增加。
2. 网络请求量差异大
在执行 install 时，Composer 只需要下载 lock 文件中指定的压缩包，网络行为集中在“下载”阶段，请求次数少且目标明确。
update 则不同：它需要先向各个包源发起大量元数据请求，比如查询某个包有哪些版本、每个版本的依赖声明等。这些“探测式”的请求数量可能成百上千，尤其当项目依赖较多时，整体响应时间叠加起来非常明显。
3. 版本决策算法开销高
Composer 使用一个名为 Solver 的组件来处理依赖解析。update 操作触发的是完整求解过程，系统必须尝试各种版本组合，确保没有冲突并满足所有约束条件（如 PHP 版本、扩展要求、版本范围等）。
这种回溯和尝试机制在数学上属于复杂问题，尤其在存在多个间接依赖或版本限制严格的情况下，计算时间会急剧上升。
- install：跳过求解，直接安装已知版本
- update：运行完整依赖求解器，耗 CPU 和时间
4. 缓存利用程度不同
虽然 Composer 有本地缓存机制，但 update 经常需要验证远程元数据是否更新，因此会绕过部分缓存主动检查新版本。而 install 更倾向于使用本地已下载的包缓存，甚至可以直接从缓存复制到 vendor 目录，极大提升速度。
如果你频繁运行 update，但实际并无版本变更需求，这部分开销就显得尤为“浪费”。
基本上就这些。简单来说，install 是按清单发货，update 是重新选品+比价+下单，自然慢得多。日常开发推荐使用 install，只有在需要升级依赖时才运行 update。合理使用 lock 文件，能大幅提升项目部署效率。
