Composer install卡在Loading composer repositories是因元数据拉取失败，需三步解决：确认镜像URL以/结尾、清缓存、删vendor和composer.lock后用--no-cache重装。
composer install 卡在 Loading composer repositories 怎么办
这基本就是元数据拉取失败，不是项目问题，也不是你网速差。Composer 启动时会先 GET packages.json（20MB+），这个请求卡在 DNS、TLS 或 CDN 节点上，表现就是停在那一行不动。
必须三步一起做：
- 执行
composer config -g repo.packagist，确认输出是完整 JSON，且url字段以/结尾，例如"https://mirrors.aliyun.com/composer/"；漏斜杠会 404 或静默 fallback - 立刻运行
composer clear-cache—— 旧缓存里存着packagist.org的元数据，换源后它根本不发请求到镜像站，只在校验旧地址 - 删掉
vendor/和composer.lock，再跑composer install --no-cache，强制走新源重新拉取全部元数据
为什么换了镜像还卡在 Resolving dependencies
这个阶段不走网络，但对 PHP 环境极其敏感。常见真实原因不是 Composer 本身慢，而是环境拖了后腿：
-
memory_limit过低（比如 128M），依赖图解析中途 OOM，反复重试 —— 临时加COMPOSER_MEMORY_LIMIT=-1测试 - 启用了
xdebug（php -v能看到），会让解析慢 5–10 倍 —— 用php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与实际 PHP 版本不匹配（如"php": "7.4"却在 PHP 8.2 上运行），触发大量降级查找逻辑 -
composer.lock里残留已下线包的引用，导致回退搜索 —— 删锁文件 + vendor 是最干净的解法
CI/CD 中 composer install 还慢？检查这四个参数是否齐备
不是“建议加”，是生产部署的硬性组合。少一个，提速就打折：
-
--no-dev：跳过require-dev包，省掉 30–60% 时间 -
--prefer-dist：强制走 ZIP 包，避免 git clone 带来的 I/O 和 SSH 开销 -
--optimize-autoloader：生成静态类映射，PHP 7.4+ 下能进 opcache -
--classmap-authoritative：告诉自动加载器“不在映射里 = 真没有”，彻底跳过文件扫描（注意：本地开发禁用，否则新增类直接Class not found）
镜像配置生效没？别信命令输出，要看真实请求
composer config -g repo.packagist 输出正确 ≠ 实际走镜像。真正验证方式只有一种：
跑 composer install -vvv 2>&1 | grep "packages.json"，日志里必须出现类似 GET https://mirrors.aliyun.com/composer/packages.json 才算成功。如果还看到 packagist.org 或 codeload.github.com，说明：
- 项目级
composer.json里写了repositories字段（哪怕值是{}或{"packagist.org": false}），全局配置会被完全屏蔽 -
composer.lock里 dist.url 还是原始 GitHub 地址 —— 镜像只代理元数据，不托管 ZIP，必须删锁文件重装才能更新 dist.url - 某些私有包或未同步的 dev 分支不在镜像中，会 fallback 到原站，但不影响主流程
最容易被忽略的是：composer.lock 不只是版本记录，它固化了 dist.url 和哈希值。换镜像后不删它，等于拿着旧地图找新仓库——所有加速动作都白做。
