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
很多凌晨突如其来的告警，根源就在于此：某次部署脚本里不小心多敲了一个 update，而恰好在那个时刻，Packagist 正在同步一个包含破坏性变更的补丁版本。
lock 文件不提交 = 放弃可重现性
必须明确一点：composer.lock 绝不是临时文件，它是 Composer 生态中保证项目依赖可重现性的唯一权威凭证。
- 如果在
.gitignore里忽略它，就意味着团队中每个成员在运行composer install时，得到的将是不同时间点的依赖快照。今天和明天安装的版本可能都不一样，“在我机器上是好的”将成为常态。 - 当团队成员的 PHP 环境不同（比如有人用 8.2，有人用 8.3），如果没有 lock 文件，
install可能会为不同的人拉取不同版本的symfony/console（因为平台约束会触发不同的依赖分支选择）。 - 安全补丁的落地，也必须依靠
composer update 特定包并提交更新后的 lock 文件，而不是靠口头通知“大家记得手动升级一下”。
还有一个常被忽略的要点：lock 文件里保存的不仅仅是版本号。它记录了每个依赖包完整的下载 URL 和 SHA256 哈希值。这意味着，即使有一天 packagist.org 完全离线，只要你拥有 lock 文件，就能从本地缓存或镜像中，精确无误地还原出整个 vendor 目录——当然，这一切的前提是，这个 lock 文件已经被妥善地提交到了版本控制系统中。
