必须配合镜像源、缓存清理和DNS修复才有效，因单纯调process-timeout仅延长总耗时，而卡在Resolving或Downloading时的瓶颈常是DNS失败、IPv6 fallback、镜像未生效或缓存污染。
改超时配置不能单独搞定 Composer 安装慢和超时问题，必须配合镜像源、缓存清理和 DNS 修复才有效。
为什么只调 process-timeout 没用
单纯执行 composer config -g process-timeout 600 只延长了 PHP 进程总耗时，但卡在 Resolving dependencies 或 Downloading 阶段时，真正瓶颈常是 DNS 解析失败、IPv6 fallback、镜像未生效或缓存污染。很多用户执行完这条命令仍失败，是因为根本没连上镜像源——composer config -g repo.packagist 输出仍是 https://packagist.org 或空值。
- 确认镜像是否生效：运行
composer config -g repo.packagist，输出必须是完整 JSON 对象，例如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 旧版 Composer（1.x）不认
repo.packagist，得用composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}' - 项目级
composer.json中的repositories字段会覆盖全局配置，需手动检查并删减冗余项
http.timeout 和 process-timeout 的区别
process-timeout 控制整个命令生命周期（含脚本执行），而 http.timeout 只管单次 HTTP 请求（比如下载一个 zip 包）。两者都要设，否则可能在下载中途就断连。
- 推荐组合：
composer config -g process-timeout 1800+composer config -g http.timeout 600 - CI/CD 环境中建议用环境变量替代配置项：
COMPOSER_PROCESS_TIMEOUT=1800和COMPOSER_HTTP_TIMEOUT=600，避免容器重启后丢失 - 若使用
php -d方式调用，记得加memory_limit=-1，否则依赖解析阶段易因内存不足被 kill
镜像源配错的三个硬伤
阿里云、腾讯云等镜像源不是“配了就行”，漏掉任一条件都会静默失效：
-
repo.packagist键名不能写成repos.packagist（多一个 s 就完全忽略） - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠返回 404） - 必须显式指定
composer类型参数：composer config -g repo.packagist composer https://...，漏掉中间的composer会被 fallback 到默认源
配完立刻执行 composer clear-cache，否则旧缓存中的 packages.json 元数据仍指向 packagist.org。
Docker 或 WSL2 环境下容易被忽略的点
在容器或子系统里跑 composer install 卡住，90% 不是超时设置低，而是底层网络或文件系统问题：
- IPv6 fallback 是隐形杀手：运行
curl -v https://packagist.org 2>&1 | grep "Connected to"，若看到 IPv6 地址后卡住，说明在等超时重试；临时方案是curl -4 -I https://packagist.org强制走 IPv4 - Docker 默认 DNS 不稳定，启动时加
--dns 8.8.8.8或在/etc/docker/daemon.json中配置全局 DNS - WSL2 下 vendor 目录挂载在 NTFS 卷上时，
Generating autoload files阶段极易 I/O 阻塞；建议把vendor放在 Linux 文件系统内（如/home/xxx/vendor），而非/mnt/c/...
最麻烦的是：这些现象都不报错，只表现为“无响应”。盯着日志看 -vvv 输出，比盲目调超时有用得多。
