Composer install和update区别是什么_Composer install update对比教程【全面】

Composer install 与 update：一字之差，天壤之别

搞混 composer install 和 composer update，是很多PHP开发者踩过的坑。其实，两者的核心区别就一句话：是否把 composer.lock 文件当作必须遵守的“施工图纸”。 前者严格按图施工，确保环境一致；后者则是撕掉旧图纸，重新设计一套方案——用错一个词，线上环境就可能崩给你看。

composer install：只认 lock 文件，追求绝对复现

千万别把 composer install 理解成“安装最新版本”。它的真实身份是“复现工程师”：只要发现 composer.lock 文件存在，它就完全无视 composer.json 里那些 ^2.1 或 dev-main 的模糊版本约束。

• 有 lock 文件：直接按文件里记录的精确版本号、文件哈希和源地址，批量下载解压。整个过程跳过复杂的依赖求解，速度快，结果100%确定。
• 没有 lock 文件：此时它会退化成初始化流程：读取 composer.json，求解依赖关系，并生成一份全新的 composer.lock。
• 关键特性：它从不修改 composer.lock。哪怕你刚刚改动了 composer.json，它也只管按旧的 lock 文件安装。
• 典型场景：CI/CD 流水线构建、生产服务器部署、以及新人克隆代码库后要做的第一件事，都应该是执行它。

composer update：无视 lock 文件，主动寻求变更

同样，别以为 composer update 只是“更新已安装的包”。它的本质是“依赖重构师”：彻底丢开现有的 composer.lock，然后根据 composer.json 里当前的所有约束条件，重新联网查询、计算，挑选出一套满足条件的最新依赖组合。这个过程必然会覆盖旧的 lock 文件。

• 核心逻辑：不管 lock 里原来锁定了什么，一律重新解析 composer.json 中的 require 和 require-dev 部分。
• 执行代价：会触发完整的依赖图遍历、版本冲突检测和回溯求解，耗时较长，且产生大量网络请求。
• 潜在风险：很可能升级依赖的次要版本（例如从 3.2.1 跳到 3.3.0），甚至主版本（如果约束写得宽，比如用了 * 或 ^2.0 || ^3.0），从而引入不兼容的变更。
• 使用技巧：支持精准控制更新范围，例如 composer update monolog/monolog 或 composer update “phpunit/*”，这样可以避免全量升级带来的不确定性。

那些年我们踩过的坑，以及如何填平

很多问题表面上是命令用错了，根源其实在于没理解 lock 文件在团队协作中的核心意义。

• 本地和CI环境装出来的 vendor 不一样？ 首先检查 composer.lock 是否被 .gitignore 忽略了，或者忘记提交到版本库了。
• 执行 update 后功能异常？ 这不是 update 命令的错，而是因为你没有在测试环境充分验证新的依赖组合，也忽略了查看相关包的更新日志（changelog）。
• 只想新增一个包，不想动其他依赖？ 别用 update。正确的姿势是使用 composer require vendor/package:version，这个命令会智能地将新包合并到现有的 lock 文件中。
• 生产环境误执行了 update？ 立即用 git checkout composer.lock && composer install 回滚到之前的锁定状态，不要试图在线上“修复”新引入的问题。

到底该用哪个？一个简单的决策逻辑

判断依据其实非常清晰：你当前的目标是“稳定复现一个已知状态”，还是“主动寻求依赖关系的变更”。

• 追求稳定复现时：克隆项目、部署上线、CI构建。请使用 composer install --no-dev（在生产环境加上 --no-dev 是标准操作，不是可选项）。
• 需要主动变更时：修复安全漏洞（例如某个 Symfony 组件的 CVE）、接入新功能 API、替换已废弃的包。请使用 composer update vendor/package，并在充分测试后，务必将新的 composer.lock 提交到版本库。
• 仅添加开发工具时：比如加个调试工具或日志组件。更安全的方式是直接运行 composer require --dev phpunit/phpunit，这比手动修改 json 再执行 update 要可靠得多。

最后必须强调一点：composer.lock 文件绝不是可有可无的“缓存”，它是整个项目依赖环境的“契约书”。一旦团队不提交它，install 命令就失去了复现的基石；一旦你在生产服务器上随手执行了 update，这份契约就被单方面撕毁了，后果可想而知。