卡在“Loading composer repositories”是因默认全量加载packagist索引导致OOM，须用Composer 2.9.6+配合阿里云/腾讯云分片镜像，并双设php -d memory_limit=512M与COMPOSER_MEMORY_LIMIT=384M，同时禁用Xdebug和插件。
composer install 卡在 “Loading composer repositories” 阶段，不是网络慢，而是默认把整个 packagist.org 的索引（含数百万包元数据）一次性拉进内存解析——老旧服务器上直接 OOM 或卡死。镜像源本身不解决这个问题，但分片加载机制依赖镜像服务端支持，目前**只有阿里云镜像和腾讯云镜像明确实现了索引分片（repository split）与增量同步能力**，华为云镜像仍为全量快照模式。
阿里云镜像的分片逻辑是：将 packages.json 拆成按首字母/哈希前缀划分的子文件（如 p/packages-0.json, p/packages-a.json），Composer 客户端通过 repositories.packagist.org.packages 配置感知分片结构，只拉取实际用到的片段。但这个能力**必须 Composer 2.9.6+ + 镜像服务端协同生效**，旧版 Composer（如 2.2.x）会退化为全量下载。
验证是否真走分片：
- 执行
composer clear-cache后运行composer install -v - 观察输出中是否出现类似
Loading https://mirrors.aliyun.com/composer/p/packages-a.json的多条独立请求（而非单个packages.json） - 若仍只看到
Loading https://mirrors.aliyun.com/composer/packages.json，说明客户端或镜像配置未对齐
常见失效原因：
-
composer config -g repos.packagist写错格式，导致 fallback 到默认源（输出含"url": "https://packagist.org"即失败） - 项目级
composer.json中定义了repositories，覆盖了全局配置，且其 URL 未指向分片镜像 - 使用了过时的镜像地址，如
https://packagist.phpcomposer.com（已停服）或https://packagist.laravel-china.org（无分片）
为什么 --prefer-dist 对索引分片没用
--prefer-dist 只影响包本体下载方式（zip vs git clone），完全不干预元数据（packages.json 及其分片）的获取路径与加载策略。它解决的是 vendor 目录 I/O 问题，不是内存爆掉的根源。
索引阶段内存爆炸发生在 Resolving dependencies 前，此时连第一个包都没开始下。你加再多 --no-dev --optimize-autoloader，也拦不住 Composer 把几 MB 的 packages.json 解析成 PHP 数组的过程。
真正起效的是：php -d memory_limit=512M COMPOSER_MEMORY_LIMIT=384M composer install -v 配合分片镜像——前者防解析崩，后者减解析量。
COMPOSER_MEMORY_LIMIT 和 php -d memory_limit 必须双设
Composer 自身有两层内存控制：
-
php -d memory_limit控制 PHP 进程总上限，低于此值直接Fatal error -
COMPOSER_MEMORY_LIMIT是 Composer 内部的软限制，用于提前终止高内存操作（如 dependency resolution），避免触发 PHP 硬限制而被 kill
老旧服务器常见情况是：PHP CLI 默认 memory_limit=128M，但 Composer 在解析分片索引时仍需 300M+ —— 只设 COMPOSER_MEMORY_LIMIT=384M 不管用，进程早被系统杀掉；只调 php -d memory_limit=512M 又可能让 Composer 在 OOM 边缘反复重试，拖慢 3–5 倍。
正确姿势：php -d memory_limit=512M COMPOSER_MEMORY_LIMIT=384M composer install
分片镜像下仍 OOM？检查 Xdebug 和插件
即使开了分片、调了内存，Loading composer repositories 阶段仍卡住或报 Allowed memory size exhausted，大概率是以下两个隐形杀手：
-
php -m | grep xdebug输出非空 → Xdebug 在 CLI 下启用会让 JSON 解析慢 4 倍以上，临时禁用：php -d xdebug.mode=off $(which composer) install - 全局安装了
hirak/prestissimo或composer-asset-plugin→ 这些插件会在 repository 加载阶段注入额外解析逻辑，抬高内存峰值，部署时务必加--no-plugins
别信“换镜像就万事大吉”。分片是服务端能力，能否落地取决于客户端版本、配置写法、环境变量、插件干扰四者齐备。少一个，packages.json 就还是全量加载。
