卡在“Loading composer repositories”是因DNS或TLS连不通元数据源；须先用curl测试连通性，再严格配置镜像（repo.packagist、type composer、URL末尾带/），并验证输出为含type和斜杠的JSON，否则静默失效。
直接结论：超时不是单一参数能解决的，必须先定位卡在哪一环——是连不上源、下载慢、还是子进程卡死。盲目加 --timeout 基本无效。
卡在 “Loading composer repositories” 怎么办
这说明 Composer 根本没开始解析依赖，纯粹是 DNS 或 TLS 连不通元数据源。日志里出现 Could not fetch https://packagist.org/packages.json 就是典型信号。
- 先用
curl -I https://packagist.org/packages.json测试连通性；返回SSL connect error是 OpenSSL 或 CA 证书问题，返回超时或卡住则是网络策略或 IPv6 干扰 - 强制走 IPv4：
CURL_IPRESOLVE=4 composer install（Linux/macOS），Windows 上用set CURL_IPRESOLVE=4再运行命令 - 镜像配置必须严格满足三要素：
repo.packagist（不能写成repos.packagist）、composer类型、URL 末尾带/，例如：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 配完立刻验证：
composer config -g repo.packagist输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，否则静默失效
http.timeout 和 process-timeout 到底该调哪个
这两个参数作用完全不同，混着调等于蒙眼改配置。
-
http.timeout控制单次 HTTP 请求（含 DNS、TLS 握手、首字节等待、body 传输）上限，默认仅 60 秒；大包下载或镜像首字节延迟高时最先触发失败 -
process-timeout控制整个composer install命令从开始到结束的总耗时上限，默认 300 秒；它包含解压、运行post-install-cmd、生成 autoloader 等所有步骤；大型项目推荐设为1200 -
http-basic.timeout是 v1 废弃项，v2 完全不读取，设了也没用 - CI/CD 中更推荐用环境变量：
COMPOSER_PROCESS_TIMEOUT=1200比命令行参数更可靠，能覆盖插件和自定义 installer 启动的子进程
为什么加了 timeout 还报 ProcessTimedOutException
这个异常本质是 PHP 的 proc_open() 子进程被强制终止，不是 Composer 自身逻辑错误。常见于网络慢、镜像未切、依赖树复杂或内存不足等场景。
- 若已设
--process-timeout=0仍失败，大概率是内存不够——检查memory_limit是否 ≥ 1.5G，尤其update解析锁文件阶段最吃内存 - 使用 git 类仓库时，每次
git clone或git checkout都计入总超时，不是单次；所以--prefer-dist能跳过 git 操作，大幅降低风险 - Docker 中执行还需确认容器没被
docker run --stop-timeout或系统级timeout包裹——那是另一层中断，Composer 看不到 - 禁用并行下载有时比加 timeout 更有效：
composer config -g use-include-path false，再配合COMPOSER_PROCESS_TIMEOUT=0
CI/CD 里怎么让 composer install 稳住
光拉长 timeout 不够，得组合出手。
- 必须配国内镜像：
composer config -g repos.packagist.org.url https://mirrors.aliyun.com/composer/ - 强制用 dist 包：
--prefer-dist，避免git clone卡住 - 跳过平台检查要谨慎：
--ignore-platform-reqs只在明确知道缺失扩展不影响构建时才加，否则会掩盖真实兼容性问题 - 清缓存是硬要求：
composer clear-cache；Windows 用户还得手动删%LOCALAPPDATA%\Composer\cache - 删掉
vendor/和composer.lock——后者硬编码了旧源地址，不清它就会反复重试失败路径
真正容易被忽略的是：镜像配置写错一个字符、少一个斜杠、类型没写 composer，都会导致配置静默失效；而 composer.lock 一旦存在，就完全绕过镜像设置，继续直连 packagist.org。这两点不确认清楚，其他操作全是白忙。
