Composer库文件更新：不改变lock文件强制拉取最新代码

composer install 从不拉新代码，只按 composer.lock 中锁定的精确版本还原 vendor/；若要获取最新代码，需先删除 composer.lock 再运行 install，或使用 composer update 指定包并配合 --no-update-with-dependencies 等参数控制更新范围。

很多开发者都遇到过这个问题：明明远程仓库推送了新代码，本地执行 `composer install`，vendor/ 目录里的文件却纹丝不动。这到底是怎么回事？其实不是命令失效了，而是它压根儿就不是干这活的——它只听 `composer.lock` 的指挥。 ## composer install 为什么没拉到最新代码？ 答案很简单：`composer install` 从不拉新代码。它只按 `composer.lock` 里记录的 exact commit hash 或 dist shasum 去还原 vendor/。哪怕远程仓库已经更新了几十个 patch 版本，只要 lock 文件没变，它就原样解压旧缓存或 zip。所以，你看到的“没更新”，本质上是 lock 文件本身已经锁死了版本源头。 ## 想跳过 lock 强制重拉，但又不想改依赖树？ 最安全的做法是：先把 `composer.lock` 删掉，然后直接跑 `composer install`。这样一来，Composer 会彻底忽略历史锁定，重新解析 `composer.json` 中的版本约束（比如 `"^2.0"`），然后从 Packagist 拉取当前满足约束的最新可用版本，并生成全新的 lock 文件。 ⚠️ 不过需要注意：这会改变整个依赖树，不只是你想更新的那个包。如果你只想更新单个包，用 `composer update monolog/monolog` 更合理——它依然受 `composer.json` 约束，但不会动其他包。另外，如果版本号没变但想强制重新下载（比如修复损坏的 zip），Composer 2.2+ 可以加 `--force-reinstall` 参数。 ## 只更新某个包的代码，不碰 lock、不升级子依赖？ 这个需求也能实现，但需要两步配合。首先在 `composer.json` 中把目标包写成精确版本号，例如 `"monolog/monolog": "3.5.0"`。然后执行 `composer update monolog/monolog --no-update-with-dependencies`（这个参数需要 Composer 2.5+）。如果终端输出中间出现 `Downloading` 行，并且 `vendor/monolog/monolog` 下文件修改时间刷新了，才算真正重拉成功。 有一个容易踩的坑：漏掉 `--no-update-with-dependencies`，默认会连带升级它的子依赖（比如 `psr/log`），容易引发隐式变更。所以这个参数务必加上。 ## 为什么清了 vendor 还是旧代码？ 很多人以为删掉 `vendor/` 就能重新下载，结果发现还是旧代码。问题的根源在于 Composer 默认会从本地缓存复用——它根本不会去网络拉取。 缓存位置可以通过 `composer config --global cache-dir` 查看。清缓存建议用 `composer clear-cache`，别手动 `rm -rf`，否则可能破坏缓存结构。清完之后再执行安装命令，终端应该会出现大量 `Downloading https://api.github.com/` 类请求。 CI/CD 中最容易忽略这一步。构建日志看似一切正常，实际产物仍然是缓存里的旧二进制，这种情况排查起来相当隐蔽。