install 按 composer.lock 精确安装，不解析依赖、不联网、速度快；update 按 composer.json 重算依赖、联网更新、修改 lock 文件，结果不可控。
核心就一条：install 是照着 composer.lock 安装，update 是按 composer.json 重算并升级。
composer install：照单抓药，求稳不求新
它默认只看项目根目录下的 composer.lock 文件，里面记录了每个包的精确版本（比如 "monolog/monolog": "2.13.0"）。Composer 就按这个清单下载、解压、放进 vendor/，一步到位。
- 有 lock 文件 → 完全跳过依赖解析，不查远程仓库，不比版本，不改 lock
- 没 lock 文件 → 退化为类似 update 的行为：读 composer.json，装最新兼容版，并生成新的 lock
- 典型场景：新同事克隆项目后执行；CI/CD 流水线部署生产环境；本地快速还原一致环境
composer update：刷新处方，主动升级
它直接忽略 lock 文件，重新读取 composer.json 中的版本约束（如 "^2.0" 或 "~3.5"），然后联网查包、解依赖冲突、选最新可用组合，最后把新版本装进 vendor 并写回 lock 文件。
- 每次运行都可能改变依赖树，哪怕只是小版本号（如从 2.12.3 升到 2.13.0）
- 会修改 composer.lock，所以更新后必须提交该文件，否则别人 install 不到你用的版本
- 可局部更新：例如
composer update guzzlehttp/guzzle只升 Guzzle，不影响其他包
为什么 install 总是比 update 快？
因为 install 是“确定性操作”：已知要下什么、从哪下、解到哪，纯 IO 操作；update 则要跑算法、发几十上百个 HTTP 请求、反复验证兼容性——尤其当项目依赖多、嵌套深时，卡住几秒甚至几分钟都不奇怪。
- 网络开销：update 需频繁访问 Packagist API 获取元数据；install 只需下载 tarball
- CPU 开销：依赖解析器在 update 里高强度运行；install 几乎不计算
- 结果可控性：install 每次结果完全一样；update 结果取决于当前远程状态
日常怎么用才不容易翻车？
记住三个动作：
- 加新包别用 install 或 update，用
composer require foo/bar——它自动写入 composer.json、装包、更新 lock - 团队协作必须把
composer.lock提交到 Git，这是保证所有人环境一致的唯一依据 - 生产环境部署脚本里只写
composer install --no-dev，永远不要出现 update
基本上就这些。install 是施工队按图纸施工，update 是设计师重画图纸再开工——用错场合，轻则返工，重则塌房。
