根本原因是网络环境导致下载失败且默认重试策略过弱；应通过环境变量composer_network_timeout和--retries参数调高超时与重试次数，并配合国内镜像源及清缓存解决。
为什么 composer install 总卡在 “Failed to download”？
根本原因不是 Composer 本身出错，而是它默认用系统级的 curl 或 php_stream 下载包时，受本地网络环境（如 DNS 污染、连接超时、TLS 握手失败）影响，且默认重试策略极弱——只重试 3 次，每次超时仅 30 秒，对国内或高延迟网络几乎无效。
改 composer.json 的 config 不起作用？
很多人误以为改项目根目录下的 composer.json 就能调全局下载行为，其实不行。config 里只能控制包安装路径、平台配置等，超时和重试必须通过全局配置或命令行参数生效。正确做法是：
- 运行
composer config -g repo.packagist composer https://packagist.phpcomposer.com（已失效，不推荐）或切换为国内镜像源（见下条） - 用
composer config -g github-oauth.github.com "your_token"解决 GitHub API 限速（若报 403） - 但最关键的超时与重试，得靠环境变量或命令行参数
真正有效的超时与重试设置（命令行 + 环境变量）
Composer 从 2.2 开始支持 COMPOSER_PROCESS_TIMEOUT 和 COMPOSER_NETWORK_TIMEOUT，但注意：COMPOSER_NETWORK_TIMEOUT 控制的是单次 HTTP 请求超时（单位秒），而 COMPOSER_PROCESS_TIMEOUT 是整个命令最长运行时间（含解压、脚本执行等），别混用。
实操建议：
- 临时提高单次请求超时：在命令前加
COMPOSER_NETWORK_TIMEOUT=300 - 强制增加重试次数：加
--retries=5（Composer 2.2+ 支持，低于此版本无效） - 组合使用最稳：
COMPOSER_NETWORK_TIMEOUT=300 composer install --retries=5
- 若仍失败，说明是 DNS 或中间代理问题，需配合镜像源 —— 推荐清华源：
composer config -g repo.packagist https://packagist.phpcomposer.com
（旧）或更可靠的：composer config -g repo.packagist https://packagist.org
+ 使用https://mirrors.tuna.tsinghua.edu.cn/composer/镜像（需额外配置）
镜像源配置后还要手动改 composer.json 吗？
不用。全局镜像源配置会自动覆盖所有项目的源地址，除非项目里显式写了 "repositories"。但要注意一个坑：composer create-project 初始化时如果网络卡住，它会缓存失败状态，此时要清空 Composer 的下载缓存：
composer clear-cache，否则即使换了镜像、调了超时，也会复现 “Failed to download”。
另外，某些企业网络会拦截 HTTPS SNI 或屏蔽 api.github.com，这时即使超时设再大也没用 —— 必须联系运维放行，或改用 SSH 方式克隆（需提前配置 git@github.com 的 SSH key 并在 composer.json 中把 vcs 类型仓库写成 git@github.com:user/repo.git）。
