卡在Resolving dependencies是DNS解析失败，非超时问题；应先用dig验证DNS、换公共DNS或hosts绑定，再配镜像并清缓存；卡在Downloading才调http.timeout，Executing command才调process-timeout。
直接调 process-timeout 或 http.timeout 很可能白等——得先看 Composer 卡在哪一层，否则改了也无效。
卡在 Resolving dependencies 是 DNS 问题，不是 timeout 能解决的
这一阶段只做域名解析（比如查 mirrors.aliyun.com 的 IP），不发 HTTP 请求，http.timeout 和 process-timeout 完全不生效。
- 运行
dig mirrors.aliyun.com @8.8.8.8，看是否返回 IPv4 地址；若超时或无响应，说明本地 DNS 不可用或被污染 - 临时换 DNS：Linux/macOS 编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows 在网络适配器里手动设 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）是否误把镜像域名指向了127.0.0.1 - 用手机热点试一次——很多企业网会屏蔽
packagist.org和 GitHub 域名，但热点通常直连通畅
卡在 Downloading https:// 才该动 http.timeout
只有到这一步才真正发起 HTTP 请求，此时 http.timeout 才起作用。它控制单次请求的完整生命周期（DNS、TLS 握手、首字节等待、body 下载），默认仅 60 秒，对国内镜像首字节延迟高的场景极易触发 cURL error 28。
- 全局设置：
composer config -g http.timeout 600（单位秒，600 = 10 分钟） - 项目级更稳妥（尤其 CI）：
"config": {"http-timeout": 600}写进composer.json - 验证是否生效：
composer config -g http.timeout应输出600；若输出空或报错，说明配置未写入 -
http-basic-timeout是 Composer v1 废弃项，v2 完全不读取，写了也无效
卡在 Executing command (CWD: ) 是子进程卡死，得调 process-timeout
这一阶段执行的是外部命令，比如 git clone、unzip、post-install-cmd 脚本。它们的总耗时受 process-timeout 控制，默认 300 秒，大型项目很容易超。
- 全局设高一点：
composer config -g process-timeout 1800 - CI 环境建议用环境变量覆盖更可靠：
COMPOSER_PROCESS_TIMEOUT=1800 - 注意：
process-timeout=0后仍失败？大概率是内存不足。检查php -r "echo ini_get('memory_limit');"，update阶段建议 ≥ 1.5G - 私有包走 Git 时，每次
git checkout都计入process-timeout总耗时，不是单次独立计时
镜像源配置错误会导致“看似成功，实则静默失效”
换源命令漏一个字符、少一个斜杠、键名写错，都会让配置完全不生效，但 Composer 不报错。
- 必须严格匹配键名：
repo.packagist（注意是repo单数，不是repos） -
type值必须是composer，不能省略，也不能拼成compose - 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/"} - 换源后必须执行
composer clear-cache，否则旧缓存还在，根本不会发新请求
最常被忽略的是：process-timeout 和 http.timeout 完全不重叠，混着调等于乱按开关；而 DNS 解析失败和镜像配置错误这两类问题，调任何 timeout 都没用——得先用 -vvv 看清最后一行停在哪，再动手。
