composer install 严格按 composer.lock 还原依赖，确保环境一致；update 则重解依赖并更新锁文件，破坏一致性。

直接运行 composer install 就能重建 vendor 目录，前提是 composer.json 和未被修改的 composer.lock 都存在。这不是“重装”，而是按锁文件精确还原——它不看网络最新版，只下载 lock 里记录的版本、哈希和源地址，确保和原来一模一样。

为什么 composer install 是首选，而不是 composer update

composer update 的本质是重新解析依赖树，把 "^2.0" 这类范围约束解析成当前最新兼容版（比如 2.10.0），并改写 composer.lock。它不是恢复，是升级。你失去的是环境一致性。

常见后果包括：

• composer update monolog/monolog 后，psr/log 等子依赖可能卡在旧版本，运行时报 Class not found
• CI/CD 流水线中混用 update，不同机器装出不同版本，部署失败难以复现
• 私有包认证失效时，update 容易卡住不动；而 install 会更快失败并暴露具体哪个包拉不到

删 vendor 后 composer install 失败的常见原因和解法

报错如 "lock file is not up to date" 或 "Could not find package in lock file"，通常不是命令错了，而是状态不干净：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 确认 composer.lock 没被 Git 标为 modified（尤其注意 Windows/Linux 换行符差异）
• 用 rm -rf vendor 彻底清空，别只删子目录（留个空 vendor/ 目录也会让 Composer 误判为“已存在”，跳过完整安装）
• 如果项目用了 --no-dev 安装，重装时必须加同样参数：composer install --no-dev，否则会多装一堆 dev-only 包
• 运行 composer validate 快速检查 composer.json 和 composer.lock 是否语法合法、结构匹配

缓存损坏比 vendor 缺失更隐蔽，必须优先清理

即使 vendor 删干净了，Composer 仍可能从 ~/.composer/cache（或 Windows 下 %APPDATA%\Composer\Cache）读取损坏的 zip 包，导致 Failed to extract vendor/package 这类解压失败错误。

正确顺序是：

• 先运行 composer clear-cache（别手动 rm -rf，Composer 会重建目录结构）
• 再 rm -rf vendor
• 最后执行 composer install

如果你用的是私有镜像或自定义 repo，还要确认 composer config --global repo.packagist 指向的是可用地址——过期的镜像配置会让 install 卡在元数据请求阶段，看起来像“没反应”。

真正容易被忽略的是：一旦 composer.lock 丢失或损坏，你就放弃了可重现性保障。它不是缓存，是锁定依据。哪怕只是临时切分支忘了 composer install，也建议立刻补上，别等报错才处理。