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），联网查最新可用版本，跑依赖求解器，找出满足全部约束的最新组合。

Github Stars Analyzer

抓取指定 GitHub用户的 Stars 项目，生成标准化中文 Markdown 报告。用户提及「分析 GitHub stars」「导出收藏项目」「汇总 GitHub 星标」「生成 stars 报告」或粘贴含 ?tab=stars 的链接时触发。执行通过 bash...

下载

• 强制重算依赖树，可能引入新版本、新冲突、甚至破坏性变更
• 一定会更新 composer.lock，记录新版本快照
• 耗时长，涉及大量网络请求和 CPU 计算
• 只应在开发阶段主动发起，且需配套测试验证

什么时候该用哪个？

日常协作和上线部署一律用 install；只有明确要升级依赖（比如修安全漏洞、用新 API）才运行 update，并及时提交更新后的 composer.lock 到 Git。

加 --no-dev 参数在生产环境是常规操作，install 支持，update 也支持，但后者仍会重新计算全部依赖——所以别在服务器上乱跑 update。

基本上就这些。install 是稳态复现，update 是动态探索。用错地方，轻则慢，重则崩。