Composer的install和update有什么区别：新手必看的核心概念解析

Composer的install和update有什么区别：新手必看的核心概念解析

composer install 为什么有时会生成 composer.lock？

这事儿其实挺简单，composer install 的行为逻辑，完全取决于一个“开关”——当前目录下有没有 composer.lock 文件。

简单来说，就两种情况：

• 有 composer.lock：那 Composer 就进入“复读机”模式。它会严格按 lock 文件里白纸黑字记录的版本号、哈希值和下载地址去安装依赖，整个过程基本不联网、不重新计算、更不会改动 lock 文件。
• 没有 composer.lock：这时候，install 命令就自动退化成了一次“首次求解”。它会读取 composer.json，运行内部的依赖解析器，计算出当前满足所有约束的最新兼容版本，下载它们，并最终生成一份全新的 composer.lock 文件。

所以，很多新手克隆项目后第一次运行 composer install，看到 lock 文件“凭空出现”，完全不必惊讶，这正是预期内的行为。不过，这里有个关键细节：通过这种方式首次生成的 lock 文件，其结果和直接运行 composer update 可能并不相同。后者会强制走一遍完整的、更激进的依赖求解流程，对于那些标记为 dev-main 或 ^3.0@dev 的不稳定版本约束，处理方式会有所区别。

composer update 默认会更新所有包，不只是你改过的

这是一个非常普遍的误解。很多人以为，我只在 composer.json 里把 "monolog/monolog": "^2.0" 改成了 "^3.0"，那么 composer update 就只会动 monolog 这一个包。

事实并非如此。它的默认行为是：重新计算整个项目的依赖关系图。这意味着，不仅是你指定的 monolog，连带着它的所有依赖，以及你项目里其他的间接依赖，比如 phpunit、symfony/polyfill 等等，都会被纳入计算范围。

• 只要这些包存在满足所有约束条件的新版本，它们就会被一并升级，哪怕你在 composer.json 里根本没提过它们。
• 真想只更新某个特定包？必须显式指定包名：composer update monolog/monolog。
• 如果还想连带更新这个包的子依赖？那就加上 --with-dependencies 选项；否则，更新可能会卡在“当前约束已满足”的状态，看似没动，实则留下了版本不匹配的隐患。

忽略这个细节的代价可能不小。比如在开发环境顺手升级了整个依赖生态，但测试用例没有覆盖到某个 polyfill 包对 DateTimeZone 行为的细微变更，结果代码上线后，时区解析就莫名其妙地出错了。

生产环境死守 composer install --no-dev，不是为了省时间

在生产环境部署时，坚持使用 composer install --no-dev，其核心价值远不止“安装快一点”。关键在于语义和部署的确定性。

• composer install --no-dev 的本质是“精确复现”。它跳过开发依赖包，并且完全跳过依赖解析这一步，直接根据 composer.lock 中锁死的哈希值和 URL 去下载对应的代码归档。整个过程是确定且可预测的。
• 而 composer update --no-dev 即使跳过了开发包，其核心仍然是“重新计算”。它依然会联网请求 Packagist API，校验 PHP 版本、扩展以及复杂的子依赖约束。这个求解过程本质上是一个 NP-hard 问题，依赖一多，50个包卡上两分钟是常事。
• 更重要的是，任何 update 操作都必然重写 composer.lock 文件。如果这个新生成的 lock 文件没有被提交到版本库，那么下一次部署就将永远无法回到之前的版本状态。
• 在 CI/CD 流水线或 Docker 构建脚本中混入 composer update