Composer update和install区别_Composer依赖更新逻辑解析【基础】

composer install 严格按 composer.lock 安装指定版本，秒级完成；无 lock 则退化为首次解析。update 重解依赖并更新 lock，require/remove 才是增删包的正确方式。

composer install 是照单抓药，不是“安装最新”

它只认 composer.lock 里的版本号，哪怕 composer.json 里写的是 "^2.0"，只要 lock 文件锁死在 "2.12.3"，就一定装这个——不联网、不比版本、不重算依赖。

• 有 composer.lock → 完全跳过解析，纯下载解压，秒级完成
• 没有 composer.lock → 退化为首次解析：读 composer.json、选最新兼容版、生成新 lock、再装
• CI/CD 部署脚本里必须用 composer install --no-dev，绝不能出现 update
• 团队协作时，composer.lock 必须提交 git；漏提 = 别人 install 出来的 vendor 和你不一样

composer update 是重画处方，不是“更新已装包”

它直接无视 composer.lock，重新跑一遍依赖求解器：查 Packagist、比约束、解冲突、挑最新组合，最后把结果写回 lock 文件。

• 每次运行都可能升级小版本（比如从 2.12.3 到 2.13.0），甚至引入破坏性变更
• composer update guzzlehttp/guzzle 可局部更新，但依然会重算整个依赖树，只是其他包版本不变
• 执行后必须提交新的 composer.lock，否则别人 install 不到你实际测试过的版本
• 安全补丁或新 API 需要时才用，且应在测试环境验证后再推上线

加新包别用 install 或 update，用 require

composer install 不改 composer.json，composer update 又太猛——它们都不是为“加一个包”设计的。

• 正确姿势是：composer require monolog/monolog:^3.0
• 它自动做三件事：写进 composer.json 的 require、装包、更新 composer.lock
• 如果误用 update 加包，很可能顺手把其他十几个包也升了，引发未知问题
• 想删包？对应用 composer remove monolog/monolog，而不是手动删 json 再 update

为什么 install 总是快，update 经常卡住？

这不是网络慢的问题，是根本逻辑不同：install 是 IO 密集型操作，update 是 CPU + 网络双密集型。

• install：已知每个包的 URL、SHA256、安装路径，批量下载解压即可
• update：要发几十个 HTTP 请求查元数据，再跑 SAT 求解器判断兼容性，嵌套深的项目可能卡 2–5 分钟
• 国内用户遇到 update 卡在 loading composer repositories，大概率是没配镜像源，不是命令本身有问题
• 生产服务器上看到 composer update 出现在部署脚本里，基本可以判定是配置错误

lock 文件不是“缓存”，是契约。它不保证“最新”，只保证“一致”。很多人把它当可删可忽略的中间产物，其实它是 Composer 体系里唯一能防止“在我机器上好好的，上线就崩”的防线。