Composer如何克隆现有项目依赖_Composer install从lock安装【规范】

结论：必须用 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 或直接拒绝执行，而不是静默修复。