curl error 28主因是dns解析或tls握手失败，非下载慢；应先换阿里云镜像源并验证生效（composer config -g repos.packagist输出须为https://mirrors.aliyun.com/composer/，且curl -i秒回200），再设http.timeout=600、process-timeout=600。
cURL error 28 不是下载慢，而是连接卡在 DNS 或 TLS 握手阶段；换国内镜像源比调 timeout 更有效，且必须验证是否真正生效。
怎么确认镜像源有没有真走通
很多人执行 composer config -g repos.packagist 后就以为搞定了，但终端里仍卡在 Downloading https://packagist.org/p/... ——说明请求根本没走到镜像站。
- 运行
composer config -g repos.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，而不是packagist.org - 手动测试镜像连通性：
curl -I https://mirrors.aliyun.com/composer/packages.json，要能秒回HTTP/2 200；如果超时、返回503或404，问题出在本地 DNS、代理或防火墙，不是 Composer 配置 - 检查项目根目录下
composer.json是否硬写了"repositories"字段——它会覆盖全局配置，得删或改成镜像地址
timeout 和 process-timeout 到底该设哪个
Composer v2 实际用的是 Guzzle 封装的 HTTP 层，不读旧版的 http-basic.timeout，也不受 PHP 的 default_socket_timeout 影响。真正起作用的是两个参数，用途完全不同：
-
process-timeout：控制整个命令生命周期（依赖解析、下载、解压、脚本执行），单位秒，默认 300，建议设为600～1200；设太高反而掩盖真实网络问题 -
http.timeout：只管单个 HTTP 请求的总耗时（DNS + 连接 + 传输），单位秒，建议设为600；注意这不是timeout（v1 遗留字段，v2 已忽略） -
http.connect-timeout：只管 TCP 连接建立阶段，弱网下容易卡住，建议同步设为30～60
设置命令示例：composer config -g process-timeout 600、composer config -g http.timeout 600、composer config -g http.connect-timeout 30
向CurlShip提交产品，这是一个对机器人友好的SaaS目录。只需一条curl命令即可发布产品，支持OG标签抓取、带徽章的dofollow链接及层级升级。
重试失败后要不要清缓存
Composer 没有断点续传，但下载是分阶段的：元数据已写入 composer.lock，临时 zip 包和部分解压内容通常保留在 vendor/.cache/ 或 ~/.composer/cache/ 中。所以多数情况下直接重试即可。
- 重试无效的典型信号：
Failed to extract、unable to open archive、Invalid argument supplied for foreach()（说明installed.json被截断） - 此时必须清理：
rm -rf vendor+composer clear-cache，再跑composer install - CI/CD 环境务必启用缓存（如 GitHub Actions 的
$HOME/.composer/cache），否则每次都是从零拉百 MB zip 包，失败率极高
为什么加 --prefer-dist 能绕过很多超时
默认情况下，Composer 优先尝试 dist（zip 包），失败才 fallback 到 source（git clone）。但某些包的 source 地址是 GitHub，而未配 github-oauth 时会触发 API 限流，表现为卡在 Cloning into ... 并最终超时。
-
--prefer-dist强制跳过 git，只走 zip 下载，体积小、校验快、失败率低 - 搭配
--no-plugins可避免旧插件（如hirak/prestissimo）引发的并发异常 - CI 场景推荐组合：
composer install --no-interaction --prefer-dist --optimize-autoloader
真正难处理的不是超时本身，而是镜像源响应异常（比如返回空 body 或缺失 Content-Length）、系统 CA 证书过期导致 TLS 握手失败、或企业网强制 HTTPS 扫描中断长连接——这些不会报明确错误，只会静默卡住，得靠 curl -v 或抓包定位。
