根本原因不是镜像慢，而是dns解析或tls握手失败触发curl error 28；应先验证连通性（curl -v），再换阿里云镜像https://mirrors.aliyun.com/composer/、清缓存、禁用packagist回退，并同步调高http.timeout和process-timeout。
根本不是镜像“慢”，而是 Composer 在加载中文镜像元数据时卡在 DNS 解析或 TLS 握手，触发了底层 cURL 超时（cURL error 28），此时调 process-timeout 完全无效。
为什么换阿里云镜像后 still 卡在 “Loading composer repositories”
这不是 Composer 配置没生效，而是系统层面连不上镜像域名——常见于 DNS 污染、WSL2 时间不同步、公司代理拦截或证书链不全。错误现象通常是：Could not resolve host mirrors.aliyun.com 或 * TLS handshake 卡住不动。
- 先验证连通性：
curl -v https://mirrors.aliyun.com/composer/packages.json，看停在哪一步 - 若卡在
Resolving：改 DNS（如设为8.8.8.8）或临时绑定 hosts（查nslookup mirrors.aliyun.com得 IP 后写入） - 若卡在
TLS handshake：检查系统时间（date），WSL2 用户需同步 Windows 时间；或临时禁用证书验证（仅内网可信环境）：composer config -g secure-http false - 别用已停用的旧镜像地址（如
https://packagist.phpcomposer.com），当前稳定地址是：https://mirrors.aliyun.com/composer/或https://packagist.proxy.tencent.com/
http.timeout 和 process-timeout 必须同时调，且作用完全不同
http.timeout 控单次 HTTP 请求（DNS+TCP+TLS+首字节），默认仅 60 秒；process-timeout 控整个命令生命周期（含解压、脚本执行等），默认 300 秒。两者独立触发，只改一个等于白调。
- 设
http.timeout应对下载卡顿：composer config -g http.timeout 600 - 设
process-timeout应对大项目 autoload 生成慢：composer config -g process-timeout 1200 - CI 环境建议用环境变量更可靠：
COMPOSER_HTTP_TIMEOUT=600 COMPOSER_PROCESS_TIMEOUT=1200 -
http-basic.timeout是 v1 废弃项，v2 完全不读，设了也无效
清缓存 + 关闭自动回退，否则镜像配置形同虚设
即使配了国内镜像，Composer 默认仍会尝试官方源失败后才切镜像，这个“回退”过程不可控且耗时；旧缓存还可能强制走旧源拉包，导致超时反复发生。
- 禁用官方源回退：
composer config -g repos.packagist false（注意不是repos.packagist.org） - 立刻清空缓存：
composer clear-cache，否则vendor目录里残留的旧包仍会触发失败请求 - 确认镜像生效：
composer config -g repos.packagist输出必须是{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}，不是packagist.org也不是空值 - 项目级
composer.json中的repositories字段会覆盖全局配置，CI 构建前务必检查是否被覆盖
最易被忽略的是：任务执行器（比如 Jenkins、GitLab CI）常复用容器或宿主机环境，COMPOSER_HOME 可能指向旧配置目录，导致你本地调好的参数在 CI 里完全不生效——每次构建前加一句 composer config -g --list | grep -E "(http|process)-timeout|repos.packagist" 才算真正确认。
