必须同时调高process-timeout和http-basic-timeout，前者控整个命令生命周期（默认300秒），后者控单次HTTP请求全过程（默认60秒），二者独立生效、不可替代，仅调其一无法解决Downloading卡顿。
超时不是网络慢，是 Composer 默认的 process-timeout 和 http-basic-timeout 两道闸门卡得太紧——只调一个，大概率白忙。
为什么改了 timeout 还是卡在 downloading？
因为 process-timeout 控整个命令生命周期（含解压、脚本执行），http-basic-timeout 才管单次 HTTP 请求（比如拉 ZIP 包）。两者独立生效：
- 解析快但下载慢 → 必须调高
http-basic-timeout - 钩子脚本卡住（如
php artisan config:cache）→ 只调http-basic-timeout没用，得加process-timeout -
http-basic-timeout仅 Composer 2.2+ 支持；旧版本只能靠--timeout硬扛
全局配置怎么写才真正生效？
别只信 composer config -g repo.packagist 的输出，要验证是否真走镜像：
- 先清缓存：
composer clear-cache - 再带日志运行：
composer update -vvv 2>&1 | grep "Downloading\|packages.json" - 看到
Downloading https://mirrors.aliyun.com/composer/packages.json才算成功；若仍是https://packagist.org/...，说明镜像没生效 - 常见失效点：项目级
composer.json里有"repositories"字段（哪怕空对象{}），会直接覆盖全局镜像
Resolving dependencies 卡住，改 timeout 完全无效
这个阶段不发 HTTP 请求，只做 DNS 解析和读取 packages.json 元数据索引。此时 http-timeout、process-timeout 全部不触发：
- 先验证 DNS：
dig packagist.org或nslookup packagist.org，看能否返回 IP - 若超时或无响应，换系统 DNS（如
114.114.114.114） - 检查是否 IPv6 fallback 导致隐形卡顿：
curl -v https://packagist.org 2>&1 | grep "Connected to"，若连到2a03:2880:...后卡住，说明是 IPv6 超时叠加 - 临时绕过：
curl -4 -I https://packagist.org；根治需系统级禁用 IPv6 或容器启动加--dns 8.8.8.8
metadata 缓存不清，换镜像也白搭
composer clear-cache 不会删掉最关键的元数据快照，它藏在：~/.composer/cache/repo/https---packagist.org/（Linux/macOS）或对应 Windows 路径里，且永不自动过期：
- 手动删掉整个目录：
rm -rf ~/.composer/cache/repo/https---packagist.org/ - Composer ≥ 2.5 可用更安全的方式：
composer update --refresh，它会强制丢弃并重拉元数据 - 删完别急着
install，先跑composer update --dry-run -v，确认日志里出现Downloading https://...才算真正刷新成功
最易被忽略的是：项目级 repositories 配置和 metadata 缓存这两处，它们会让所有 timeout 调整和镜像切换都静默失效——不查日志、不删缓存、不扫项目配置，就永远在原地打转。
