结论：必须用 composer install 且确保存在 composer.lock 文件；因为 install 精确复现 lock 中的版本、commit hash 和路径哈希，而 update 会重新解析依赖导致版本不一致，引发运行错误。
直接说结论：用 composer install，不是 composer update，且必须确保项目根目录存在 composer.lock 文件。
为什么不能用 composer update 来“克隆依赖”
很多人误以为 composer update 是“同步别人项目的依赖”，其实它会根据 composer.json 重新解析最新兼容版本，忽略 composer.lock 的约束。结果就是：你装的包版本和原项目不一致，可能引发运行时错误、行为差异甚至测试失败。
真正克隆依赖的行为，是严格复现 lock 文件中记录的每个包名、版本号、commit hash（对 dev 分支）、以及安装路径哈希 —— 这只有 composer install 能做到。
-
composer install：读composer.lock→ 精确下载指定版本 → 不改 lock 文件 -
composer update：读composer.json→ 求解新依赖图 → 覆盖写入composer.lock - 首次克隆项目后没 run 过
install，vendor/目录为空或不完整，直接跑项目大概率报Class not found
composer install 执行前必须检查的三件事
它看起来简单，但失败常源于几个隐性前提没满足。
- 确认当前目录下有
composer.lock—— 如果只有composer.json，install会退化为update行为（并生成新 lock），这不是克隆，是重建 - PHP 版本需 ≥
composer.lock中记录的platform.php值（可在 lock 文件顶部找到，如"platform": {"php": ">=8.1"}）；版本低会导致跳过某些包或报错Your requirements could not be resolved - 已配置好正确的仓库源（尤其是私有包）：如果 lock 里有来自
packagist.org以外的源（如 GitLab、私有 Satis），需提前在~/.composer/auth.json或项目级auth.json中配好 token，否则卡在Cloning into '...'或报401 Unauthorized
团队协作中 lock 文件的维护规范
composer.lock 不是“可选文件”，它是依赖快照，必须提交进 Git。
- 禁止在
.gitignore中忽略composer.lock - 每次
composer require或composer update后，lock 文件变更需和composer.json一起提交 - 多人协作时，若有人本地执行了
update但只提交了json，其他人install仍会按旧 lock 装 —— 这会导致环境不一致；所以建议：所有依赖变更必须走 PR + lock 文件 diff 审查 - CI 环境应始终使用
composer install --no-dev（生产环境）或--with-all-dependencies（测试环境），避免因本地 dev 配置污染构建
最常被忽略的一点：lock 文件里记录的 content-hash 是对 composer.json 内容的校验值。如果 json 被手动编辑但没运行 update 或 install，lock 文件就处于“逻辑不一致”状态 —— 此时 install 会警告 The lock file does not contain require-dev information 或直接拒绝执行，而不是静默修复。
