必须用 composer install 而不是 composer update，因为它严格按 composer.lock 还原精确依赖版本、哈希和安装状态，确保环境一致；update 会忽略 lock 文件重新解析，导致不可控升级与构建不一致。

直接用 composer install，不是 composer update —— 这是还原已有项目依赖环境的唯一正确方式。

为什么必须用 composer install 而不是 composer update

composer install 会严格读取 composer.lock 中记录的每个包的精确版本、提交哈希（对 git 包）、安装路径和依赖树快照，确保所有机器装的完全一致；composer update 则忽略 lock 文件，重新解析 composer.json 并拉取符合约束的最新兼容版本，结果不可控。

• CI/CD 流水线中误用 update → 构建产物不一致，线上偶发报错
• 团队协作时有人运行了 update 又提交了新 lock → 其他人 install 后行为突变
• 生产环境部署若执行 update → 可能引入未测试的次要版本，触发 BC break

composer install 执行前必须检查的三件事

缺一不可，否则大概率失败或装错：

• composer.lock 文件必须存在且未被 git 忽略（检查 .gitignore 是否误写了 composer.lock）
• vendor/ 目录必须为空或不存在（若存在旧依赖，install 不会清理它，可能引发混杂加载）
• php 版本和已启用扩展需满足 composer.lock 中各包的 platform 声明（例如 lock 里写 "php": "^8.1"，而你本地是 PHP 7.4，则会跳过兼容包甚至报错）

克隆项目后标准操作流程（含常见报错应对）

假设你刚 git clone 下来一个 laravel 或 symfony 项目：

cd your-project rm -rf vendor composer.lock.bak  # 确保干净 ls -la | grep composer.lock      # 确认 lock 文件在根目录 
检查 PHP 版本是否匹配 lock 中声明
php -v grep -A5 '"platform"' composer.lock | grep php
执行还原（不加任何参数！）
composer install
若报错 "Your requirements could not be resolved"：
通常是因为 PHP 版本/扩展不满足，不是依赖冲突 —— 别急着删 lock

如果 composer install 报 Package x requires ext-yaml but it is not installed，说明 composer.lock 记录的某个包依赖 ext-yaml，但当前 PHP 缺失该扩展——此时应安装扩展，而不是降级 PHP 或改 composer.json。

想“克隆依赖”到另一台机器？别手动复制 vendor/

vendor/ 是构建产物，不是源码，包含大量绝对路径、生成类、平台相关二进制（如 phpunit 的 phar、symfony/flex 的 recipe 补丁），跨机器复制几乎必然出错。

• windows 上复制到 linux：文件权限丢失、换行符混乱、symlink 失效
• 不同 PHP 架构（x86_64 vs aarch64）下扩展二进制无法加载
• autoload_classmap.php 和 autoload_psr4.php 里的路径绑定本地路径，迁移后自动加载失败

真正可移植的只有 composer.json + composer.lock —— 它们才是依赖的“源代码”。