换源是提高Composer下载成功率的刚性前提；执行composer config -g repo.packagist，输出必须是国内镜像地址如https://mirrors.aliyun.com/composer/，为空、null或仍为packagist.org则未生效，且须清缓存并用-vvv验证真实请求URL。
换源不是“可选优化”，是提高 Composer 下载成功率的刚性前提；不换，其他操作基本白做。
怎么确认镜像源是否生效
执行 composer config -g repo.packagist，输出必须是类似 "https://mirrors.aliyun.com/composer/" 的国内地址。如果为空、null、或仍是 "https://packagist.org"，说明没生效。
- 旧版 Composer（1.x）要用
repos.packagist，不是repo.packagist；写错键名会导致静默失败 - 项目级
composer.json里有repositories字段时，会覆盖全局配置——删掉或加"packagist.org": false才能强制走镜像 - 验证真实请求路径：加
-vvv运行composer install，日志里出现mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn才算真走镜像
为什么换了镜像还卡在 Downloading
常见现象是命令执行了，但下载速度仍为 0 KB/s 或反复超时。这不是镜像慢，而是请求根本没发到镜像站。
- 本地 DNS 缓存未刷新：
curl -I https://mirrors.aliyun.com/composer/packages.json应秒回200；若超时或503，先查网络或代理设置 - 缓存未清：
composer clear-cache必须紧跟换源之后执行，否则 Composer 仍在用旧的海外元数据索引 - 用了已停服源：
https://packagist.phpcomposer.com自 2025 年底起不可用，现在返回404或空响应，但 Composer 不报错，只重试至超时 - IPv6 fallback 卡顿：Linux/macOS 默认启用 IPv6，Composer 会先尝试
[2a02:...]:443几秒无响应后才 fallback 到 IPv4——加环境变量COMPOSER_IPV4=1强制走 IPv4
哪些参数能真正提升成功率（非速度）
成功率低的本质是网络不稳定下的中断和重试失败，不是带宽问题。以下配置直接降低失败概率：
- 延长超时：
composer config -g http.timeout 600和composer config -g process-timeout 600，默认 300 秒对弱网太激进 - 增加重试次数：
composer config -g retries 5（Composer 2.2+ 支持），避免单次 TLS 握手失败就退出 - 禁用并行干扰：
composer config -g parallel-downloads 1或临时用--no-parallel，某些企业防火墙会拦截并发连接 - 跳过 SSL 验证（仅调试）：
composer config -g secure-http false，但生产环境严禁——它绕过证书校验，不是提速，是降安全水位
CI/CD 场景下容易被忽略的关键点
CI 环境失败率高，往往因为复用逻辑不对或权限缺失，而非网络本身。
- 必须复用
~/.composer/cache目录，而不是vendor；后者每次重建，前者能命中已有 dist 包和元数据 - GitHub 限速常被误判为网络问题：报
GithubRateLimitException或403时，需在~/.composer/auth.json中配github-oauth.github.comToken -
--prefer-dist必须显式带上，否则某些包可能 fallback 到慢速 Git clone；镜像站只缓存 dist，不缓存 source - 别信
hirak/prestissimo：Composer 2.x 已原生支持并发，该插件不仅无效，还可能静默降级为单线程
最常被跳过的动作是清缓存和验证 -vvv 日志——这两步不做，你永远不知道请求到底发去了哪，也就不知道该调哪个参数。
