composer install 是精确还原环境的契约执行器，严格按 composer.lock 中记录的哈希、版本、源地址安装依赖，不解析约束、不升级、不查 packagist。
composer install 为什么必须基于 composer.lock 执行
它不是“安装依赖”的通用命令，而是“精确还原环境”的契约执行器。只要项目里有 composer.lock，composer install 就会严格按其中记录的每个包的完整哈希、版本、源地址来下载和解压，不查 Packagist，不解析约束，不升级任何东西。
常见错误现象：团队中有人在本地删掉 composer.lock 后跑 composer install，结果生成了新 lock 文件并提交；CI 构建时拉取这个新 lock，却因某依赖子包在新版本中移除了某个方法而报错——本质是把 composer install 当成了 composer update 的简化版。
- 生产部署、CI/CD 流水线、协作开发环境，只允许运行
composer install - 本地开发想加新功能？用
composer require，它会同时更新composer.json和composer.lock -
composer install在找不到composer.lock时会自动 fallback 到composer update行为——这是最隐蔽也最危险的默认逻辑
Laravel/Symfony 等框架如何依赖 composer install 的行为保证启动一致性
现代 PHP 框架（如 Laravel 10+、Symfony 6+）的入口文件（public/index.php 或 bin/console）第一行就是 require __DIR__.'/../vendor/autoload.php';。这个文件由 composer install 生成，且其内容直接受 composer.lock 控制。
如果 composer install 被绕过或行为失准，autoload.php 中的类映射、PSR-4 规则、甚至 autoloader 注册顺序都可能变化。典型表现是：本地能跑，部署后报 Class App\Http\Controllers\HomeController not found，但文件路径和命名空间完全正确——问题出在 autoload 文件没按预期生成。
- Laravel 的
artisan命令依赖vendor/composer/autoload_classmap.php中预生成的类路径，该文件仅在composer install --optimize-autoloader或composer dump-autoload -o后存在 - Symfony 的容器编译阶段会扫描
src/下所有类，若 PSR-4 映射未被composer install正确注册，会导致服务定义加载失败 - 框架的 service provider 自动发现（如 Laravel 的 package discovery）依赖
composer.json中的extra字段，而该字段只在composer install时被读取并写入vendor/composer/installed.json
composer install --no-dev --optimize-autoloader 在生产环境的实际影响
这两个参数不是“锦上添花”，而是生产环境的硬性要求。去掉 --no-dev 会让 phpunit、mockery 等开发依赖进入 vendor/，不仅增大部署体积，更可能因 dev 包引入的 autoloader 冲突导致运行时异常；不加 --optimize-autoloader 则让框架每次请求都走 PSR-4 目录遍历，而非查静态 classmap，实测 QPS 下降 15–20%（基于 PHP 8.2 + OPcache 场景）。
-
--no-dev不只是跳过安装，还会从最终的autoload.php中彻底剔除autoload-dev配置项 -
--optimize-autoloader实际触发classmap生成，并将所有匹配文件路径写入vendor/composer/autoload_classmap.php，绕过文件系统查找 - 某些框架（如 Slim 4）的中间件注册逻辑依赖优化后的 autoloader 加载顺序，未启用该参数可能导致中间件未被识别
为什么 vendor/ 目录不该被提交，但 composer.lock 必须提交
vendor/ 是产物，不是源码——它由 composer install 根据 composer.lock 动态生成，重复提交只会污染 Git 历史、拖慢克隆速度、引发合并冲突。而 composer.lock 是契约：它记录了每个依赖的精确版本、校验哈希、源类型（dist vs source），是跨机器、跨环境复现一致构建的唯一依据。
容易被忽略的细节：当项目使用私有包仓库（如 Satis 或 Private Packagist）时，composer.lock 还会保存该包的完整下载 URL 和 reference，一旦缺失，composer install 将无法定位包源，直接失败。
- Git 忽略规则必须包含
/vendor，但明确放行/composer.lock - CI 构建脚本第一行应是
composer install --no-interaction --no-dev --optimize-autoloader，而非composer update - 若使用 Docker，
composer install应在构建阶段执行，而非挂载 volume 后运行——否则vendor/会被覆盖，autoloader 失效
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
