Composer update和install究竟有何不同？ (composer.lock详解)

composer install 严格按 composer.lock 安装已锁定版本，确保环境一致；composer update 重解析依赖并更新 lock，用于升级。lock 文件必须提交 Git，它是依赖一致性的唯一事实来源。

composer install 是“照单抓药”，只认 composer.lock

它不查远程包仓库、不重新解析依赖、不改任何版本决策——只要 composer.lock 存在，就按里面写死的版本号、哈希值、源地址，一模一样地装进 vendor/。结果完全可预测，速度也快。

• 有 composer.lock → 严格安装 lock 里记录的每个包的确切版本（比如 monolog/monolog v2.10.2）
• 没有 composer.lock → 退化为首次解析 composer.json，生成新 lock 并安装（仅发生在全新项目或误删 lock 后）
• 生产部署、CI/CD、新人拉代码后，必须用 composer install --no-dev，这是唯一安全做法
• 即使 composer.json 里写着 "^2.0"，install 也绝不会升级到 v2.11.0 —— 它根本不看那行

composer update 是“重开处方”，主动忽略 composer.lock

它把现有 composer.lock 当废纸，重新联网请求 packagist，运行依赖求解器，找出所有满足 composer.json 中约束（如 ^3.5 或 dev-main）的最新组合。这个过程可能引入新 bug、破坏性变更，且必然改写 lock 文件。

• 执行后一定会更新 composer.lock，哪怕只是微小修订版（v4.2.1 → v4.2.3）
• 耗时明显更长：大量 HTTP 请求 + PHP 计算依赖图 + 下载新包
• 可以精准控制范围：composer update doctrine/dbal 只更新这一个包及其子依赖
• 别在服务器上跑 update：它不区分环境，--no-dev 只影响安装行为，不影响求解过程本身

为什么 composer.lock 必须提交到 Git？

因为它是团队和线上环境一致性的唯一事实来源。不提交 lock，等于让每个人、每次部署都随机“抽卡”——今天装的 symfony/http-kernel v6.4.3，明天 CI 跑出来可能是 v6.4.7，而后者悄悄改了某个事件监听器的参数顺序。

Cardify卡片工坊

使用Markdown一键生成精美的小红书知识卡片

下载

• composer.json 是“需求说明书”，描述“想要什么”；composer.lock 是“验收清单”，记录“实际拿到什么”
• 删除 lock 后运行 install，等价于一次隐式 update，风险不可控
• 如果某次 update 导致测试失败，回滚只需 git checkout 上一版 lock，再 install 即可复原

常见错误现象与应对

这些不是报错，而是你已经在踩坑的信号：

• 「本地能跑，CI 报 Class not found」→ 很可能 CI 用了 install，但你本地没提交新生成的 lock，或者有人偷偷跑了 update 没提交 lock
• 「composer install 提示 “lock file is not up to date”」→ 说明 composer.json 被改过（比如加了 require），但没运行 update 或 require 更新 lock，此时应先确认是否需要升级，再决定是 update 还是 require xxx
• 「update 后 vendor 里多出一堆没声明的包」→ Composer 自动拉入了传递依赖的新版本，而旧 lock 里没锁死它们的版本，暴露了语义化版本不严谨的问题