删 vendor 后必须用 composer install 还原，因它严格按 composer.lock 安装相同版本；composer update 会忽略 lock 文件、重算依赖，导致版本漂移和环境不一致。
删掉 vendor 目录后，直接 composer install 就能还原，前提是项目根目录下有有效的 composer.lock 文件。
为什么不能用 composer update 还原？
composer update 会忽略 composer.lock，根据 composer.json 重新解析依赖树，可能装上新版包（哪怕只差一个小版本），导致行为不一致甚至报错。还原的目标是“和之前一模一样”，所以必须走 install 流程。
- ✅ 正确：删 vendor → 确保有
composer.lock→ 运行composer install - ❌ 错误：删 vendor → 直接
composer update→ 包版本漂移、环境不一致 - ⚠️ 注意：
composer install在没有composer.lock时会退化为update行为，所以先检查是否存在该文件
composer install 执行失败的常见原因
不是所有“还原失败”都源于命令用错，更可能是环境或配置问题：
-
composer.lock文件损坏或格式错误（比如被手动编辑过、换行符异常）→ 可用json_decode(file_get_contents('composer.lock'), true)快速验证是否合法 JSON - PHP 版本不匹配：
composer.lock中记录了每个包要求的 PHP 版本范围，当前环境不满足时会跳过安装或报Your requirements could not be resolved - 平台配置冲突：如
config.platform.php被设为高版本，但实际运行环境低，会导致依赖解析失败 - 网络问题或源不可达：尤其国内没配镜像时，
packagist.org响应超时，可临时加-vvv查看卡在哪一步
想跳过某些步骤加速还原？谨慎使用这些选项
composer install 默认会执行 autoload 生成、脚本钩子（scripts）、插件初始化等，有些场景可以跳过，但别盲目加：
-
--no-scripts：跳过post-install-cmd等钩子 → 适合纯依赖还原，但若项目依赖脚本生成配置/资源，会出问题 -
--no-autoloader：不生成vendor/autoload.php→ 后续 PHP 脚本肯定报Class not found，仅调试 autoload 机制时用 -
--prefer-dist（默认）vs--prefer-source：前者下载 zip 包更快；后者克隆 Git 仓库，适合要改包源码或调试时 —— 但还原一致性不受影响
真正容易被忽略的是 composer.lock 的时效性：它不是“一次生成永久有效”。如果团队中有人运行过 composer update 但没提交新的 lock 文件，你本地按旧 lock 还原出来的代码，其实已经和线上/他人环境不一致了。
