必须同时配置腾讯云镜像和http.timeout、process-timeout参数，否则90%超时仍复现；镜像解决“慢”，两个timeout解决“断”，且需清缓存、验证配置输出及实际请求url是否含mirrors.cloud.tencent.com。
只配腾讯云镜像但不调 http.timeout 和 process-timeout，90% 的超时仍会复现——镜像解决的是“慢”，两个 timeout 解决的是“断”。
确认腾讯云镜像是否真在生效
很多人执行了 composer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/ 就以为搞定了，其实 Composer 可能根本没走这个地址。必须做三件事：
- 先清缓存：
composer clear-cache（否则仍用旧索引，镜像等于白配） - 查配置是否写对：
composer config -g repo.packagist，输出必须是{"type": "composer", "url": "https://mirrors.cloud.tencent.com/composer/"}；若为空、为packagist.org或带错斜杠，就无效 - 看实际请求：
composer show laravel/framework 11.* -vvv | grep -i url，输出中必须出现mirrors.cloud.tencent.com；若看到repo.packagist.org is default，说明镜像完全未加载
为什么设了镜像还报 cURL error 28 或 The process timed out
镜像只加速 dist 包下载，以下场景它不介入，timeout 依然触发：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
"prefer-source": true开启时，Composer 直连 Git 仓库（如github.com），绕过镜像；此时失败是 Git 层问题，http.timeout完全无效 - 项目依赖含私有仓库（如
git@xxx或自建 Satis），Composer 会 fallback 直连，逐个尝试并超时重试，拖垮整体耗时 - CI/CD 容器每次启动都是干净环境，
COMPOSER_HOME未固化会导致镜像配置丢失；必须在构建脚本开头显式执行配置命令
必须同步调的两个 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 下载阶段无效
CI/CD 中稳定拉包的关键操作
容器环境更易超时，不能只靠本地配置：
- CI 脚本开头必须显式设置：
export COMPOSER_HOME=/tmp/composer，再运行composer config -g，否则每次重启都丢配置 - 强制走 IPv4：
COMPOSER_IPV4=1 composer install（国内多数镜像站对 IPv6 支持不完整，隐性延迟叠加） - 别用
composer update上 CI：它会重新解析依赖树，耗时远高于install；应基于已提交的composer.lock执行 -
process-timeout超过 7200 秒会被 Composer 主动忽略，强制回退到 300 秒——这是硬编码限制，设再大也没用
最常被忽略的是：镜像配置后不 clear-cache，或项目级 repositories 字段覆盖全局，导致所有 timeout 调整都白费。验证一定要落到实际请求 URL 上，而不是配置命令有没有报错。
