高峰期 composer install 卡住的根本原因是依赖解析和自动加载生成在高并发下争抢 I/O 和 CPU，导致 vendor 写入冲突、缓存锁竞争及 PSR-4 扫描叠加；应禁用 classmap 动态扫描与 lock 哈希检查，启用 --no-scripts、--no-autoloader 和 --classmap-authoritative，并复用缓存、避免并发 dump-autoload。
高峰期执行 composer install 为什么卡住？
根本原因不是网络慢，而是依赖解析和自动加载生成在高并发下争抢 I/O 和 CPU。尤其当多个 CI 任务同时跑 composer install，vendor 目录写入冲突、缓存文件锁竞争、PSR-4 路径扫描叠加，会导致单次执行从几秒拖到一分多钟。
必须关掉的两个默认行为
高峰流水线里，composer install 默认会做两件低效事：动态扫描所有源码目录生成 classmap；每次运行都检查并更新 composer.lock 的哈希一致性。这两步在 CI 环境中纯属冗余。
- 用
--no-scripts跳过 post-install-cmd 等钩子（除非你真依赖它们） - 加
--no-autoloader，把 autoload 生成挪到构建末尾统一做，避免每个 job 都重复 dump
生产环境 autoloader 必须用 classmap-authoritative 模式
开发时用 PSR-4 动态映射没问题，但高峰期每秒数百请求，autoload 器反复 stat 文件系统是性能黑洞。启用 --classmap-authoritative 后，Composer 会完全跳过文件系统扫描，只查预生成的 autoload_classmap.php —— 这个映射表必须由 composer dump-autoload --optimize --classmap-authoritative 提前生成并提交进镜像或 artifact。
注意：classmap-authoritative 在开发机上不要开，否则新增类不 reload 就报错；它只适合打包后不可变的部署包。
CI 流水线里 vendor 目录不能每次都重装
高频构建时，composer install 应该尽量复用已下载的包。关键配置有三个：
-
COMPOSER_CACHE_DIR环境变量指向共享缓存卷（如/ci/cache/composer），避免重复下载 -
composer install --prefer-dist --no-interaction强制走压缩包而非 git clone - 在 job 开头加判断：
if [ -f vendor/autoload.php ]; then echo "skip install"; else composer install ...; fi
真正要警惕的是 lock 文件变更触发全量重装——把 composer.lock 的校验逻辑从构建阶段移到代码提交门禁（pre-commit hook 或 PR check）里更稳妥。
高峰负载下最易被忽略的一点：composer dump-autoload 本身不是原子操作，若在多进程并发写入同一 vendor 目录，可能生成损坏的 autoload_static.php。务必确保它只在单点构建完成后再执行，且输出路径不与其他 job 冲突。
