Resolving dependencies 阶段卡住是 DNS 问题，需检查并更换 DNS；Downloading 阶段才生效 http.timeout，须配合镜像源；Executing 阶段超时由 process-timeout 控制；Autoloader 生成慢属 I/O 瓶颈，非网络问题。
卡在 Resolving dependencies 时别碰 timeout 配置
这一步根本没发 HTTP 请求，只是查 DNS，http.timeout 和 process-timeout 完全无效。现象是长时间停住、无网络活动、composer install 日志卡在第一行。
- 用
dig mirrors.aliyun.com @8.8.8.8验证本地 DNS 是否可用；若超时或返回空，说明 DNS 被污染或不可达 - 临时改 DNS：Linux/macOS 编辑
/etc/resolv.conf加nameserver 8.8.8.8；Windows 在网络适配器 IPv4 属性里手动设 - 检查
/etc/hosts（或C:\Windows\System32\drivers\etc\hosts）是否误写死了镜像域名到127.0.0.1 - 手机热点直连测试——很多企业网会静默拦截
packagist.org域名解析，但热点通常通畅
Downloading 阶段才该调 http.timeout 和镜像源
只有这时 Composer 才真正发起 HTTP 下载请求，http.timeout 生效，且必须配合镜像源使用，否则换参也没用。
- 全局设置：
composer config -g http.timeout 600（单位秒，建议 600 起步） - 项目级更稳妥（尤其 CI）：在
composer.json的"config"段加"http.timeout": 600 - 必须同步切镜像源：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/（末尾斜杠不能少） - 换源后立即执行
composer clear-cache，否则旧缓存仍走失败地址
Executing command 或整体卡死得调 process-timeout
这步涉及 git clone、unzip、post-install-cmd 等子进程，由 process-timeout 控制，默认仅 300 秒，和 HTTP 无关。
- 临时绕过：
composer install --process-timeout=0（禁用）或--process-timeout=1200（20 分钟） - 永久生效：
composer config -g process-timeout 1200 - 若已设为 0 仍失败，大概率是内存不足——检查 PHP
memory_limit是否 ≥ 1.5G，尤其update解析锁文件阶段 - CI 中务必显式传环境变量：
COMPOSER_PROCESS_TIMEOUT=1200，否则容器重启后配置丢失
autoload 生成慢不是网络问题，是 I/O 和扫描逻辑瓶颈
卡在 Generating autoload files 后无响应，99% 是 PHP 递归扫描 vendor 目录导致，尤其 WSL2、Docker for Mac 或 NTFS 挂载卷上更明显。
- 跳过安装时生成：
composer install --no-autoloader，装完再手动运行composer dump-autoload --optimize - 生产环境推荐加
--classmap-authoritative，避免运行时遍历目录 - 禁用 symlink（如
composer install --no-scripts --no-plugins）可减少符号链接解析开销 - 某些项目含大量 PSR-4 映射但类文件极少，
--optimize-autoloader反而让autoload_classmap.php膨胀，需权衡
实际操作中，最易被忽略的是「卡在哪一层」这个判断动作。Resolving、Downloading、Executing、Autoloader 四个阶段对应完全不同的机制和参数，混着调只会浪费时间。定位清楚再动配置，比盲目加 timeout 有效十倍。
