根本原因是Composer默认超时设置过短，process-timeout仅控制脚本和下载阶段，HTTP层超时由cURL控制且需环境变量或镜像源优化解决。
composer install 或 update 卡住 / 报 timeout 错误
根本原因不是网络慢，而是 composer 默认的请求超时太短（通常 300 秒），尤其在下载大包（如 laravel/framework、symfony/symfony）或源站响应延迟时直接中断。
实操建议：
- 临时提高超时：运行命令时加
-vvv看具体卡在哪，再用--timeout=600显式延长，例如：composer update --timeout=600 - 永久生效需改全局配置：执行
composer config -g process-timeout 1800（单位秒，1800 = 30 分钟） - 注意：这个配置只影响
install/update中的脚本执行和包下载阶段，不影响 HTTP 连接本身的底层超时（那是 cURL 控制的）
HTTP 请求层超时仍报 cURL error 28
cURL error 28: Operation timed out after 300000 milliseconds with 0 bytes received 这类错误说明是 HTTP 层超时了，process-timeout 完全不生效——它管不了网络连接本身。
实操建议：
- 必须通过环境变量控制 cURL 行为：
COMPOSER_HOME下的auth.json不起作用，得靠系统级设置 - Linux/macOS：运行前设
export COMPOSER_PROCESS_TIMEOUT=1800（仅对 process-timeout 有效），真正要调 HTTP 超时，得加curl.cainfo和http.timeout—— 但 composer 不暴露这个接口 - 更可靠的做法：换国内镜像源 + 关闭 HTTPS 验证（仅限可信内网）：
composer config -g repo.packagist composer https://packagist.phpcomposer.com，再配合composer config -g secure-http false
使用阿里云 / 华为云镜像后还是超时
镜像源只是加速下载，不代表服务器响应一定快；如果本地 DNS 解析慢、出口带宽被占满、或镜像节点临时拥塞，照样会触发超时。
实操建议：
- 确认镜像是否真生效：运行
composer config -g repos.packagist，输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，不是packagist.org - 绕过 DNS 缓存：临时在
/etc/hosts（macOS/Linux）或C:\Windows\System32\drivers\etc\hosts（Windows）里绑定镜像 IP，比如：123.56.123.45 mirrors.aliyun.com - 禁用并行下载降低压力：
composer config -g disable-tls true（不推荐）或更稳妥的composer config -g concurrent-connections 1
CI/CD 流水线中 Composer 超时反复失败
CI 环境常受限于内存、DNS 策略、代理策略，且默认超时往往比本地更短（如 GitHub Actions 默认 600 秒 job 超时，但 composer 自身还会提前中断）。
实操建议：
- 在 workflow 文件中显式加大 timeout：GitHub Actions 加
timeout-minutes: 25；GitLab CI 加timeout: 25m - 预热 vendor 缓存：用
composer install --no-interaction --no-progress --prefer-dist --optimize-autoloader，跳过 dev 包和交互提示 - 最关键的一步：把
COMPOSER_CACHE_DIR指向一个可持久化的路径（如 GitHub Actions 的${{ runner.temp }}/composer-cache），避免每次重下
超时问题本质是时间、网络、配置三者叠加的结果。最容易被忽略的是：你以为改了 process-timeout 就万事大吉，但它对 cURL 层完全无效；而换镜像也不等于零延迟——DNS、TCP 握手、TLS 握手每一步都可能拖垮整个流程。
