全局代理仅在特定场景必要：企业内网仅开放代理出口、依赖未镜像的GitHub私有仓库、CI无公网出口且无法配项目级镜像；盲目启用反致失败，因Composer严格分流HTTP/HTTPS请求，漏配https-proxy或格式错误将静默失效。
全局代理 vs 镜像源：本质是链路不同，不是“选哪个更快”
因为很多人根本没分清 Composer 请求的两类流量：元数据查询（走 packagist.org 或镜像）和实际包下载（ZIP 或 git clone）。全局代理试图“一揽子解决”，但实际只对其中一部分有效，且容易干扰另一部分。
哪些场景下全局代理确实比镜像更必要？
只有当你的网络环境完全无法直连 HTTPS 服务（比如企业内网仅开放 HTTP/HTTPS 代理出口），或者你依赖大量未托管在 Packagist 镜像中的 GitHub 私有仓库（vcs 类型）、GitLab 自建源时，才需要代理。这时镜像源本身无法覆盖这些请求。
-
composer install卡在Cloning xxx from github.com—— 这是 Git 层问题，镜像源不生效，必须配git config --global http.https://github.com.proxy -
file could not be downloaded且curl -I https://mirrors.aliyun.com/composer/packages.json也失败 —— 说明网络层不通，镜像再快也没用 - CI 环境无公网出口、又没权限配置项目级镜像（如 GitHub Actions 中某些受限 runner）——只能靠
http-proxy/https-proxy环境变量兜底
为什么盲目开全局代理反而让 Composer 更慢甚至失败？
Composer 对协议分流极其严格：http-proxy 不处理 HTTPS 请求，而 packagist.org 及所有主流镜像全是 HTTPS。漏配 https-proxy 就等于没配；配了但 URL 缺少 http:// 前缀（比如写成 127.0.0.1:7890），Composer 会静默忽略；更麻烦的是，一旦同时设置了 repo.packagist 和 https-proxy，部分请求可能被劫持到代理，结果返回 404 或 fallback 到官方源。
- 验证是否真生效：
composer config -g --list | grep -E "(http|https)-proxy"，两行都得有，且格式合法（无空格、末尾无换行、带http://） - 别在
php.ini里设http_proxy环境变量——这会让所有 PHP HTTP 请求（包括镜像请求）都走代理，彻底绕过镜像 - 代理地址含特殊字符（如
@或:）必须先rawurlencode()，否则 URI 解析截断，连接直接拒绝
微服务或团队协作中，全局代理配置几乎必然出问题
全局配置（composer config -g）无法随代码提交，也无法被 CI 流水线复现。A 服务用腾讯云镜像，B 服务 CI 脚本却读不到全局配置、默认走官方源，C 服务又混用了私有仓库+镜像，最终 composer.lock 在不同环境 install 出不同版本。真正可追踪、可验证的方式，是把 "repositories": {"packagist.org": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" }} 显式写进每个项目的 composer.json。
镜像和代理不是二选一，而是分层控制：元数据走镜像，Git 克隆走 Git 自身代理，GitHub API 走 Token 认证。混用或强行统一，往往比单独用更难排查。
