答案是必须同步配置http.timeout和process-timeout参数并执行三步验证：清缓存、检查config输出是否为完整JSON、用-vvv确认日志中出现镜像域名；镜像仅加速dist包下载，prefer-source或私有仓库场景下不生效。
换镜像源本身不能解决超时，只配镜像不调 timeout 参数，90% 的 The process timed out 或 cURL error 28 仍会复现。
镜像配置写对了但没走？三步验证必须做
很多人执行 composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ 就以为完事，其实 Composer 很可能根本没用这个地址。
- 先清缓存：
composer clear-cache—— 否则旧的packages.json索引还在本地，照样连packagist.org - 查配置是否真写进去了：
composer config -g repo.packagist，输出必须是完整 JSON，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；若为空、报错或显示packagist.org，说明配置失败 - 看实际请求地址：
composer show laravel/framework -vvv 2>&1 | grep -i url，日志里必须出现mirrors.aliyun.com或mirrors.cloud.tencent.com；如果看到repo.packagist.org is default，就是镜像完全未加载
为什么设了镜像还超时？这些场景镜像不生效
腾讯云和阿里云镜像只加速 dist 包下载（即 zip/tar 归档），以下情况它不介入，http.timeout 也无效：
-
"prefer-source": true开启时，Composer 直连 GitHub/GitLab 等 Git 仓库，绕过所有镜像；此时失败是 Git 层问题，不是 Composer 配置问题 - 项目依赖含私有仓库（如
git@xxx、自建 Satis 或https://private.example.com），Composer 会 fallback 逐个直连并重试，拖垮整体耗时 - CI/CD 容器每次启动都是干净环境，
COMPOSER_HOME未固化会导致全局配置丢失；必须在构建脚本开头显式执行镜像和 timeout 配置命令
必须同步改的两个 timeout 参数
http.timeout 和 process-timeout 控制不同阶段，缺一不可：
-
http.timeout：控制单次 HTTP 请求（DNS、TLS 握手、首字节等待、body 下载），默认仅 60 秒；腾讯云/阿里云镜像首字节偶尔延迟高，建议设为600：composer config -g http.timeout 600 -
process-timeout：控制整个命令生命周期（含解压、脚本执行、autoloader 生成），默认 300 秒；大项目跑post-install-cmd易超，建议设为1200：composer config -g process-timeout 1200 -
http-basic.timeout是 v1 废弃项，v2+ 完全不读；--timeout=600只影响命令总周期，对 HTTP 下载阶段无效
阿里云 vs 腾讯云：选哪个更稳？
阿里云镜像同步更快、CDN 节点覆盖更广、HTTPS 更稳定，且对 Composer 2.1+ 兼容性最好，推荐作为开发机默认源；腾讯云镜像偶尔有新包同步延迟（尤其刚发布几小时内），若 composer require xxx 找不到最新版，可临时切回官方源验证：composer config -g --unset repos.packagist。
注意 URL 必须以 / 结尾，漏掉会拼出错误路径（如 /composerpackages.json）导致 404；-g 参数也不能漏，否则只改当前项目，不是你想要的“所有项目都快起来”。
