curl error 28 是因默认300秒下载超时导致，尤其在国内源不稳定或大包场景；应设 composer_process_timeout=1200 等调高超时，并确认换源生效、排除dns/代理干扰、启用缓存与重试策略。
composer install 时卡在 downloading，提示 cURL error 28
这是典型的连接超时，不是网络不通，而是默认 300 秒下载单个包太短，尤其在国内源不稳定或大包（如 laravel/framework）场景下极易触发。curl_setopt(): CURLOPT_TIMEOUT value of 0 is not supported 这类报错也常伴随出现——说明你可能误设了 0 或负数。
- 临时解决：加
-vvv看卡在哪一步，再用COMPOSER_PROCESS_TIMEOUT=1200 COMPOSER_TIMEOUT=1200 composer install提高全局超时（单位秒） - 根本写法：在
composer.json顶层加"config": { "process-timeout": 1200, "github-protocols": ["https"] }，避免 git 协议握手拖慢 - 注意：
process-timeout控制的是执行外部命令（如 git clone）的时长，timeout（旧版）已弃用，新版 Composer 用http-basic或github-oauth配置时，实际生效的是process-timeout
换源后还是 timeout？检查 DNS 和 HTTP 代理是否冲突
国内换阿里、腾讯源后仍超时，大概率是本地环境有隐形干扰。Composer 默认走系统 curl，而很多公司/校园网络会劫持 DNS 或强制代理，导致 HTTPS 请求卡在 TLS 握手阶段。
- 先运行
composer config -g repos.packagist.org确认当前全局源是否真生效（输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}） - 用
curl -v https://mirrors.aliyun.com/composer/packages.json手动测源站连通性，看是否卡在* Connected to mirrors.aliyun.com后无响应 - 如果手动 curl 也卡，尝试加
--resolve mirrors.aliyun.com:443:114.114.114.114强制指定 DNS，排除本地 DNS 污染 - 开发机开了代理（如 Charles/Fiddler），必须关掉——Composer 不读
HTTP_PROXY环境变量，但某些系统级 curl 会继承，造成 SSL 验证失败+静默超时
CI/CD 流水线里 composer install 随机失败，怎么稳住？
GitHub Actions、GitLab CI 等环境资源受限，内存小、网络抖动大，单纯调大 timeout 不够，得配合缓存和降级策略。
- 务必启用 Composer 缓存：CI 脚本开头加
composer config -g cache-dir "$HOME/.composer/cache"，再用cache步骤缓存该目录 - 加
--no-interaction --prefer-dist --optimize-autoloader参数组合：跳过交互、强制走 zip 包而非 git clone、减少 autoload 生成耗时 - 关键动作加重试：比如用
timeout 600 bash -c 'until composer install; do sleep 10; done'，避免单次网络抖动直接失败 - 不要在 CI 中用
composer update—— 它会重新解析依赖树，比install更耗时且易受网络影响
Composer 的 timeout 不是孤立参数，它和 DNS、SSL、源地址、包分发方式（dist vs source）、甚至 PHP 的 stream context 都耦合在一起。最容易被忽略的是：你以为改了 process-timeout 就万事大吉，但真正卡住的可能是上游 CDN 返回 503 后 Composer 没做重试，或者你的私有包仓库证书过期了却没报明确错误。
