composer config -g repo.packagist.org.proxy 仅代理元数据请求（如 packages.json），不代理 dist.zip 下载；后者仍直连 GitHub，需额外配置 ssl-proxy 且地址末尾不能带 /，并清理缓存与 composer.lock。
composer config -g repo.packagist.org.proxy 为什么没效果
配了代理却依然卡在 Downloading https://api.github.com/，说明你只改了元数据源的代理，但 zip 包下载仍走直连。Composer 的 proxy 配置只影响 repo.packagist.org 这一层（即包列表、版本信息），不控制实际 dist 文件的 HTTP 请求路径。
验证方式：运行 composer install -vvv | grep "Downloading"，如果看到 https://codeload.github.com/ 或 https://api.github.com/，就证明代理没覆盖到这一步。
- 必须同时设置
ssl-proxy（尤其 HTTPS 场景下，否则 TLS 握手失败） - 代理地址不能带尾部斜杠：
http://127.0.0.1:7890✅，http://127.0.0.1:7890/❌ - 旧版 Composer（socks5://，会静默忽略
真正加速 GitHub zip 下载的三种可行路径
元数据快没用，dist 慢才是真瓶颈。国内访问 codeload.github.com 常见 TLS 超时、DNS 解析慢、连接重置——这些不是换镜像源能解决的，得绕开 GitHub 域名。
-
个人开发首选：用
ghproxy.com类反向代理，在composer.json中为包显式重写dist.url，例如："dist": {"url": "https://ghproxy.com/https://codeload.github.com/laravel/framework/zip/refs/tags/v10.48.12"} -
全局生效（需清理 lock）：执行
composer config -g github-protocols https，强制所有 GitHub 请求走 HTTPS（避免 git 协议触发 SSH 认证或代理转发失败） -
企业/团队推荐：部署
satis或toran proxy，把codeloadzip 缓存到内网，composer.lock中的 dist URL 自动指向内网地址
--repository 参数为何经常被误用
--repository 只在 composer install 和 composer update 时影响元数据拉取环节，对已写死在 composer.lock 里的 dist.url 完全无效。很多人删了 vendor、换了 --repository，结果还是从 github.com 下载，就是因为 lock 文件没动。
-
--repository=https://mirrors.aliyun.com/composer/✅（注意不是--repository-url） - 必须先删掉现有
composer.lock，再跑composer install --repository=...，否则无意义 -
composer require不识别该参数，它只走当前配置的全局源 - CI 环境中若缓存了旧 lock，提速配置会被跳过——建议在 CI 脚本里加
rm composer.lock显式清除
验证是否真正起效的关键命令
别光看终端进度条，要看日志里实际请求发给了谁。最直接的验证是抓取真实 HTTP 目标：
- 执行
composer install -vvv 2>&1 | grep -E "(Loading|Downloading)" - 正常应看到类似
Loading composer repositories from https://mirrors.aliyun.com/composer/（元数据层） - 以及
Downloading https://ghproxy.com/https://codeload.github.com/...或内网地址（dist 层） - 如果任一环节还出现
github.com或api.github.com，说明对应层未被代理覆盖
复杂点在于：元数据源、dist 下载、OAuth token、SSH 配置、PHP 扩展（如 curl、openssl）全部耦合在一起，改一处可能暴露另一处问题。最容易被忽略的是 composer.lock 的残留影响——它像一个沉默的开关，表面配置全对，实际执行全走老路。
