composer install 超时主因是默认配置不适应CI/企业网环境：300秒超时、2次重试、无缓存、强依赖GitHub认证；应优先换阿里云镜像、调高process-timeout与http-timeout、启用缓存及代理配置。
composer install 超时不是网络慢的锅，而是默认配置在 CI 或企业网环境下天然“不耐受”——300 秒超时、2 次重试、无缓存、强依赖 GitHub 交互认证，四者叠加，失败是常态，成功才需要运气。
改镜像源 + 调超时时间是最小成本见效方案
国内直连 packagist.org 基本等于裸奔：DNS 解析卡顿、TLS 握手失败、CDN 回源延迟，都会触发 The process timed out。换源不是“加速”，是绕过故障链路。
- 全局切阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 同时调高两个关键超时（缺一不可）：
composer config -g process-timeout 1800
composer config -g http-timeout 600process-timeout控制整个命令生命周期，http-timeout控制单次 HTTP 请求；设成 0 表示禁用，但 CI 中不建议，稳比快重要 - 验证是否生效：
composer config -l | grep -E "(repo|timeout)"
CI 环境必须显式启用缓存和降级策略
CI 每次都是全新容器，不挂载缓存就等于每次重下 100+ MB 的 zip 包——这不是超时，是自找压力。
- 强制走 dist 包（跳过 git clone）：
--prefer-dist - 关掉所有干扰项：
--no-interaction --no-progress --no-scripts（尤其--no-scripts能避开php artisan key:generate等卡死钩子） - 复用 Composer 全局缓存目录：GitHub Actions 中加
cache: $HOME/.composer/cache；GitLab CI 中用cache: key: composer-cache paths: [$HOME/.composer/cache] - 环境变量兜底：
COMPOSER_PROCESS_TIMEOUT=2000
避免因未登录 GitHub 触发限流（403 不报错，只静默卡住）
COMPOSER_AUTH='{"github-oauth": {"github.com": "xxx"}}'
公司内网/代理环境要同时配 HTTP_PROXY 和 HTTPS_PROXY
只设 HTTP_PROXY 是常见错误。Composer 默认全走 HTTPS，不设 HTTPS_PROXY 就会直连，而直连在防火墙后必然 Connection timed out。
- Linux/macOS：
export HTTP_PROXY=http://proxy.company.com:8080
export HTTPS_PROXY=http://proxy.company.com:8080 - Windows cmd：
set HTTP_PROXY=http://proxy.company.com:8080
set HTTPS_PROXY=http://proxy.company.com:8080 - 若企业代理使用自签名证书，还需临时禁用校验：
git config --global http.sslVerify false
（仅限内网可信环境）
别信“重装 Composer”或“升级 PHP”，先看日志在哪卡住
超时位置决定解法：下载阶段卡？执行脚本卡？还是 DNS 解析卡？盲目调参数不如加个 -v 看清最后一行输出。
- 加详细日志：
composer install -v，观察停在Downloading ...还是Executing command (CWD): php artisan ... - 如果是 DNS 问题，
ping mirrors.aliyun.com通但curl -I https://mirrors.aliyun.com/composer/packages.json不通，大概率是 TLS 版本或 SNI 被拦截 - 清理缓存不是万能解药，但值得试：
composer clear-cache
（注意：Windows 缓存路径是%APPDATA%\Composer）
process-timeout 却忽略 HTTPS_PROXY 没配，或者在没开缓存的 CI 里硬扛 5 分钟下载。稳住节奏：先换源、再配代理、然后挂缓存、最后看日志定位卡点。 
