composer install 用于根据 composer.lock 精确还原依赖，不安装 Composer 工具本身；它仅在含 composer.json 的项目根目录下执行，五种必须场景包括 CI/CD 构建、生产部署、新成员拉代码等，无锁文件时会退化为 update 导致版本失控。
composer install 不是安装 Composer 工具本身
你不需要、也不应该运行 composer install 来“安装 Composer”。composer 是一个全局 CLI 工具，得先用官方 installer 或包管理器（如 apt、brew）装到系统里；而 composer install 只在已有 PHP 项目中起作用——它读 composer.lock，还原依赖的**确切版本**。
常见错误现象：Could not locate a composer.json file，说明当前目录不是项目根目录，或压根没 PHP 项目结构。
- 检查是否在含
composer.json的目录下执行命令 - 刚克隆项目却报错？先
ls -a确认composer.json是否被 .gitignore 忽略或漏提交 - 本地没装 Composer？运行
composer --version验证；没输出就先装工具本身，别急着install
必须手动运行 composer install 的五种典型场景
composer install 是环境一致性锚点，不是可选项。它只照 composer.lock 执行，不计算、不试探、不改锁文件。
- CI/CD 流水线构建阶段（常配
--no-dev） - 生产服务器首次部署或 vendor 被删后恢复
- 团队成员新拉代码，且项目已提交
composer.lock - 本地删了
vendor目录但保留composer.lock，需快速复原 - Docker 构建时，在
COPY composer.lock .后立即composer install
跳过这步直接 composer update，等于放弃版本锁定——线上可能突然 Class not found。
没有 composer.lock 时 install 会悄悄 fallback 到 update
这是最隐蔽也最危险的行为：composer install 在找不到 composer.lock 时，会自动退化为 composer update，重新解析 composer.json 并生成新锁文件。
后果很直接：你本地装的包版本，和同事、CI、线上完全不同。
- 初始化新项目后，立刻
git add composer.lock，哪怕它是空的（可用touch composer.lock占位） - 团队应约定：所有
composer.lock文件必须提交 Git，禁止.gitignore - CI 脚本里发现
composer update，基本等于埋雷——构建结果不可预测
init 和 create-project 完全不是一回事
别用 composer init 启动新项目。它只生成空 composer.json，不建目录、不装包、不跑脚本、不生成 vendor/autoload.php。填错 name 格式或漏 autoload 配置，后续 dump-autoload 就失败。
真正该用的是 composer create-project：
- 它拉取模板包（如
laravel/laravel），自动创建干净目录结构 - 执行
post-create-project-cmd（比如生成.env、运行php artisan key:generate） - 自动完成
composer install，vendor 和 autoload 全就绪
手写 composer.json + init + require + install 这套流程，本质是在重复模板包已封装好的逻辑——省时间的方式，是选对命令，不是填对表单。
