超时问题需分三层定位：DNS解析卡在Resolving dependencies时换DNS或hosts；HTTP下载卡在Downloading时调http.timeout和镜像源；子进程卡在Executing command时调process-timeout。
超时不是配置写错了，是网络链路或参数粒度没对上——必须先定位卡在哪一层，再动对应参数。
看 -vvv 输出最后一行，确认卡在 Resolving dependencies
这一步只做 DNS 解析，不发 HTTP 请求，http.timeout 和代理完全无效。常见现象是命令挂住不动、无错误提示、dig packagist.org 超时或返回空。
- 运行
dig mirrors.aliyun.com @114.114.114.114，检查是否返回有效 IPv4 地址 - 临时换 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.com域名
卡在 Downloading https://... 才该调 http.timeout 和镜像源
只有这时 Composer 才真正发起 HTTP 请求，http.timeout 和 http.proxy 才起作用。镜像源配置错误常静默失效，必须验证输出。
- 全局设超时：
composer config -g http.timeout 600（单位秒，建议 300～600） - 项目级更稳妥（尤其 CI）：
"config": {"http.timeout": 600}写进composer.json - 换阿里云镜像：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（末尾斜杠不能少） - 验证是否生效：
composer config -g repo.packagist输出必须是完整 JSON，如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 换源后必须执行：
composer clear-cache，否则旧缓存仍走失败地址
卡在 Executing command 或整体 install/update 超时，得调 process-timeout
这步涉及 git clone、unzip、post-install-cmd 等子进程，由 process-timeout 控制，默认仅 300 秒，和 HTTP 请求无关。
- 临时延长：
composer install --process-timeout=1200（20 分钟）或--process-timeout=0（禁用，慎用） - 全局生效：
composer config -g process-timeout 1200 - CI 环境推荐用环境变量：
COMPOSER_PROCESS_TIMEOUT=1200，它比命令行参数更能覆盖插件启动的子进程 - 若已设为 0 仍失败，大概率是内存不足——检查 PHP
memory_limit是否 ≥ 1.5G，尤其update解析锁文件阶段
CI 环境中容易被忽略的硬伤
容器重启后配置丢失、SSH 地址未处理、WSL2 元数据配置异常、硬编码仓库未切换镜像，都会让前面所有 timeout 设置白费。
- CI 启动脚本里必须重复执行镜像配置 +
clear-cache，不能依赖“之前配过” - 私有包用 SSH 地址时，CI 需预置
~/.ssh/config或改用 HTTPS 克隆（避免 Git 协议卡死） - WSL2 下注意
symlink性能问题，可加--no-scripts --no-plugins快速跳过 autoload 生成 -
--prefer-dist强制下 ZIP 包，比--prefer-source（走 git clone）稳定得多
最易被忽略的是：同一超时现象背后可能是 DNS、HTTP、子进程三层完全不同的故障，-vvv 最后一行就是唯一判据；没有这步，所有参数调整都是盲调。
