composer install 严格按 composer.lock 安装,结果可预测、速度快,适用于部署和初始化;composer update 忽略 lock 文件,重新解析依赖并更新 lock,耗时长且有风险,仅用于开发阶段主动升级依赖。

核心区别就一条:是否尊重 composer.lock 文件。
composer install:照单抓药
它默认只读取 composer.lock,按里面写死的版本号下载安装。所有包的版本、哈希值、源地址都已确定,跳过依赖解析,直接批量下载解压。
- 有
lock文件 → 严格按它装,结果完全可预测 - 没
lock文件 → 退化为首次解析composer.json,生成新lock - 不改
lock,只读不写 - 速度快,适合部署、CI/CD、新人拉代码后初始化
composer update:刷新处方
它主动忽略 composer.lock,重新扫描 composer.json 的版本约束(比如 ^2.1 或 dev-main),联网查最新可用版本,跑依赖求解器,找出满足全部约束的最新组合。
- 强制重算依赖树,可能引入新版本、新冲突、甚至破坏性变更
- 一定会更新
composer.lock,记录新版本快照 - 耗时长,涉及大量网络请求和 CPU 计算
- 只应在开发阶段主动发起,且需配套测试验证
什么时候该用哪个?
日常协作和上线部署一律用 install;只有明确要升级依赖(比如修安全漏洞、用新 API)才运行 update,并及时提交更新后的 composer.lock 到 git。
加 --no-dev 参数在生产环境是常规操作,install 支持,update 也支持,但后者仍会重新计算全部依赖——所以别在服务器上乱跑 update。
基本上就这些。install 是稳态复现,update 是动态探索。用错地方,轻则慢,重则崩。