卡在Resolving dependencies是DNS解析问题，需检查并更换DNS；卡在Downloading才涉及镜像和http.timeout配置。
直接换国内镜像源 + 清缓存，90% 的“超时”根本不是超时，而是连不上 packagist.org。
卡在 Resolving dependencies 是 DNS 问题，不是 timeout 能救的
这一步 Composer 只做域名解析（比如查 mirrors.aliyun.com 或 packagist.org 的 IP），不发 HTTP 请求、不读代理、不认 http.timeout。你调再大的超时都没用。
- 运行
dig mirrors.aliyun.com @114.114.114.114，看是否返回有效 IPv4 地址；若超时或无响应，说明本地 DNS 被污染或不可用 - 临时换 DNS：Linux/macOS 编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows 在网络适配器里手动设 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）是否误把mirrors.aliyun.com指向了127.0.0.1或错误 IP - 用手机热点试一次——很多企业网会屏蔽
packagist.org和 GitHub 域名，但热点通常直连通畅
卡在 Downloading https://... 才该动 http.timeout 和镜像配置
只有到这一步，Composer 才真正发起 HTTP 请求，此时 http.timeout 和 http.proxy 才起作用。
- 全局延长超时：
composer config -g http.timeout 600（单位秒，600 = 10 分钟） - 项目级更稳妥（尤其 CI 环境）：在
composer.json的"config"段加"http.timeout": 600 - 镜像 URL 必须是 HTTPS 且末尾带
/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出非法路径/composerpackages.json） - 验证是否真生效：
composer config -g repo.packagist输出必须是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}
镜像配置失败常静默不生效，curl -I 比看日志更可靠
换源命令漏一个字符、少一个斜杠、type 写错，都会导致配置“看似成功”，实则完全没走镜像。
- 必须严格匹配键名：
repo.packagist（注意是repo单数，不是repos） -
type值必须是composer，不能省略，也不能拼成compose - 换源后必须执行
composer clear-cache，否则旧缓存仍会复用失败地址 - 用
curl -I https://mirrors.aliyun.com/composer/packages.json直接测镜像源 HTTP 状态，比等 Composer 日志快得多
process-timeout 和 COMPOSER_PROCESS_TIMEOUT 控的是总耗时，不是单次下载
很多人混淆 http.timeout 和 process-timeout：前者只管单次 HTTP 请求（比如下 zip 包），后者管整个 composer install 进程的最大运行时间。
- CI 中建议显式设置：
COMPOSER_PROCESS_TIMEOUT=1200（20 分钟），避免容器重启后丢失 - 子进程卡死（如
Executing command: git clone）只受process-timeout影响，跟http.timeout无关 - 禁用并行下载能显著降低连接压力：
composer config -g use-include-path false，配合COMPOSER_PROCESS_TIMEOUT=0（部分版本更认这个）
最常被忽略的一点：镜像同步有 5–30 分钟延迟，新包发布后立刻 require 失败，不一定是你配置错了，而是阿里云/腾讯云还没拉到最新 packages.json。这时候临时切回官方源验证，比反复调参更快。
