根本区别在于是否重新计算依赖版本关系：install 严格按 composer.lock 安装确切版本，不查远程、不改 lock；update 则忽略 lock，重解依赖并更新 lock。
根本区别在于：是否重新计算依赖版本关系。
composer install 是“照单执行”
它优先读取 composer.lock 文件，严格按其中记录的**确切版本号**安装包。不查询远程仓库、不比对新版本、不解决冲突、不修改 lock 文件。
- 如果 lock 文件存在，直接下载并解压对应版本到 vendor 目录
- 如果 lock 文件不存在，Composer 会临时解析 composer.json，生成 lock 并安装——这只是初始化行为，不是常规逻辑
- 整个过程无网络元数据请求（除首次生成 lock 外），速度极快
- 部署和协作时用它，确保所有环境行为一致
composer update 是“重新处方”
它主动忽略 composer.lock，重新读取 composer.json 中的版本约束（如 ^2.1 或 ~3.0），触发完整依赖求解流程。
- 向 Packagist 等源发起大量 API 请求，获取各包最新可用版本及依赖图谱
- 运行 SAT 求解器处理嵌套依赖、版本冲突与约束兼容性
- 确定一组满足全部规则的最新组合，并写入新的 composer.lock
- 可能引入破坏性变更，必须在测试环境验证后再提交 lock
锁文件（lock）是二者行为分水岭
composer.lock 不是缓存，而是**可重现安装的契约文件**。
- install 只读 lock：它是稳定性的锚点，保证今天和三年后装出来的 vendor 完全一样
- update 只写 lock：它是变更的记录者，每次执行都会覆盖旧内容，反映本次升级结果
- 团队必须把 composer.lock 提交进 Git，否则 install 就失去意义
什么时候该用哪个命令？
看目标：要“复现”，就用 install；要“升级”，才用 update。
- 克隆项目后、CI 构建、线上部署 → 一律 composer install
- 修复安全漏洞、接入新功能、替换过时包 → 运行 composer update（或限定范围如 composer update monolog/monolog）
- 添加新依赖时，推荐用 composer require foo/bar，它自动更新 lock 并安装，比手动改 json + update 更安全
