Composer镜像配置必须同时满足四要素：-g、repo.packagist（单数小写）、composer（type值）、HTTPS且末尾带/，缺一即静默失效；代理需同时设proxy和ssl-proxy；多镜像须配"canonical":false才并发；下载加速依赖parallel-downloads与http-max-concurrent-downloads全局配置。
直接配代理 + 多镜像并行下载，比在 Composer 前硬套 Nginx/HAProxy 更稳、更快、更少故障点。
composer config -g proxy 和 ssl-proxy 必须同时设
Composer 100% 走 HTTPS 请求，只配 repo.packagist.org.proxy 不生效——它会尝试用 HTTP 代理转发 HTTPS 流量，结果是静默超时或 502。必须补上 repo.packagist.org.ssl-proxy 才能真正走通 TLS 隧道。
- 正确写法（以 Clash HTTP 代理为例）：
composer config -g repo.packagist.org.proxy http://127.0.0.1:7890和composer config -g repo.packagist.org.ssl-proxy http://127.0.0.1:7890 - SOCKS5 代理需 Composer ≥ 2.2，且协议必须写全：
socks5://127.0.0.1:7891，漏掉socks5://会被当成普通 HTTP 地址解析失败 - 验证是否生效：运行
composer config -g查看输出中是否有这两项；再执行curl -x http://127.0.0.1:7890 https://packagist.org/packages.json确认代理本身可用
多镜像源必须设 "canonical": false 才触发并发分发
只在 composer.json 的 repositories 里加几个镜像地址，不设 "canonical": false，Composer 默认只当 fallback 用——查第一个失败才试第二个，根本不会并发请求。
- 正确配置示例（注意
canonical是布尔值，不是字符串）：{ "repositories": [ { "type": "composer", "url": "https://mirrors.aliyun.com/composer/", "canonical": false }, { "type": "composer", "url": "https://packagist.phpcomposer.com/", "canonical": false } ] } - 若其中一个是官方源（
https://packagist.org），也必须显式设"canonical": false，否则 Composer 会把它当作“唯一权威源”，其他镜像退化为只读 fallback - 该字段控制的是“是否允许并行查询多个源的 metadata”，不是下载阶段的分流；dist 包下载靠的是
parallel-downloads参数
parallel-downloads 和 http-max-concurrent-downloads 是 dist 下载提速关键
Composer 默认最多并发 6 个 dist 包下载（zip/tar），对 CI/CD 批量构建明显不够。这两个参数才是实际起效的并发阈值，且必须全局设（-g），项目级 config 不影响下载器行为。
- 推荐值（兼顾稳定性与吞吐）：
composer config -g parallel-downloads 15和composer config -g http-max-concurrent-downloads 8 -
parallel-downloads控制总并发任务数（含 metadata 查询 + dist 下载），http-max-concurrent-downloads专管 dist 下载连接数，后者不能超过前者 - 设太高反而容易触发镜像站限流（如阿里云镜像对单 IP 每秒请求数有限制），15/8 是多数国内镜像实测较稳的上限
- 禁用无意义重试：
composer config -g github-protocols ["https"]，避免 SSH 协议卡住整个流程
L4/L7 代理在 Composer 场景下极易成为瓶颈
Nginx 或 HAProxy 做 Composer 流量入口，不是“加了就稳”，而是引入新故障面：短连接洪峰压垮 proxy_buffer、健康检查无法感知 metadata 同步延迟、所有请求一视同仁无法区分 /packages.json 和 /dist/xxx.zip。
- 典型症状：
Loading composer repositories卡住几十秒，日志显示大量Connection refused或503 Service Temporarily Unavailable，但后端镜像站本身完全正常 - 若真需统一出口（如审计要求），底线方案是 L4 + L7 协同：HAProxy（mode tcp）做连接卸载 + leastconn 负载，后端接 Nginx（mode http）仅做路由和健康检查，且健康检查 URI 必须是
/packages.json，间隔 ≤20s - 绝大多数场景，删掉代理层，直接靠 Composer 原生多镜像 + 并发参数，延迟更低、成功率更高、排障路径更短
最常被忽略的一点：镜像源之间的同步延迟是客观存在的，"canonical": false 并发查多个源时，可能拿到不同时间点的 packages.json，导致依赖解析冲突；生产环境务必搭配 composer.lock 提交，而非依赖实时解析。
