composer install 默认单线程调度，因依赖拓扑排序、串行I/O、同步钩子及不可并发的autoload合并导致性能瓶颈；实测 --no-interaction --no-progress --no-scripts --no-autoloader 组合可显著提速。
vendor 目录生成慢，不是因为磁盘写入慢，而是 Composer 在 install/update 过程中默认启用完整依赖解析、逐包哈希校验、递归 autoload 加载和串行 I/O 调度——这些操作在大型项目（300+ 包、lock 文件超 10MB）下会吃满 CPU 并阻塞主线程。
composer install 默认为什么是单线程调度
Composer 本身不支持多线程下载或并行安装，所有包按依赖拓扑顺序排队：获取元数据 → 下载 dist 或 source → 校验 SHA256 → 解压 → 执行 install 钩子 → 写 autoload 映射。哪怕你开了 16 核 CPU，composer install 也只用一个 PHP 进程跑完全流程。
- 每个包的
install钩子（如post-install-cmd）默认同步执行，Laravel 项目里常见的php artisan storage:link或前端构建脚本会卡住整个流程 -
dump-autoload是纯 CPU 密集型操作，PHP 解析全部composer.lock+ 扫描所有autoload规则 + 生成 classmap 数组，无法拆分 - 即使启用了国内镜像，元数据请求仍串行，
repositories每多配一个源，就多一次 HTTP 探测
哪些参数能真正绕过调度瓶颈
关键不是“加速”，而是“跳过非必要调度环节”。以下参数组合经实测可将 Laravel + 50+ 私有包项目的 composer install 从 8.2s 降到 4.7s：
-
--no-interaction：跳过所有交互确认（比如是否执行脚本），CI/CD 必加，否则命令可能挂起等待 stdin -
--no-progress：禁用 ANSI 进度条，减少日志写入开销，在 CI 环境下省几百毫秒 -
--no-scripts：直接跳过所有post-install-cmd和pre-autoload-dump，适合部署阶段已由其他流程接管的场景 -
--no-autoloader：不生成vendor/autoload.php，后续手动composer dump-autoload --optimize控制时机
注意：--no-autoloader 后必须补上 composer dump-autoload --optimize，否则运行时会报 Class not found；且该命令不能替代 install 阶段的优化，它只处理你本地代码，不更新 vendor 包的 autoload 映射。
autoload 生成阶段的调度陷阱
很多人以为 composer dump-autoload -o 是优化重点，其实它只是个“缓存预热”动作，真正的调度重头戏在 install 阶段：Composer 会为每个包单独解析其 composer.json 中的 autoload 字段，再合并进全局 classmap。这个过程不可并发，且极易被污染：
- 某个包的
"autoload": {"psr-4": {"": "src/"}}如果没限定命名空间前缀，就会把整个src/扫进 classmap，哪怕你只用其中 1 个类 -
require-dev包里的autoload-dev规则（如"Tests\": "tests/"）若没加--no-dev，也会混入 classmap，增大数组体积、拖慢反序列化 - 老版本包用
"classmap": ["src/", "tests/"]，会导致 tests/ 下所有 .php 文件路径全写进autoload_classmap.php，删目录风险极高
验证是否真生效：打开 vendor/composer/autoload_real.php，如果 findFile() 方法里只剩 if ($classMap = $this->classMap) 分支，且彻底删掉了 foreach ($this->prefixesPsr4 循环，才算调度精简到位。
最常被忽略的一点：COMPOSER_HOME 缓存路径未统一时，每次 install 都要重新下载 zip 包；而 opcache.enable=1 和 opcache.save_comments=0 对 autoload 性能的影响，远大于任何 -o 参数——但这两项不在 Composer 控制范围内，得靠运维配 PHP 环境。
