Composer不存在Composer-Binary-Proxy配置项，卡顿主因是HTTP并发请求触发镜像QPS限流；应设composer config -g repos.packagist.org.concurrent-downloads 2，并配对设置http-proxy与https-proxy。
Composer Binary Proxy 不存在，别配错配置项
根本就没有叫 Composer-Binary-Proxy 的官方组件或配置项——这是常见误传，源于把 http-proxy/https-proxy、repos.packagist.org.concurrent-downloads 或第三方插件（如已废弃的 hirak/prestissimo）名字记混了。所有所谓“Binary Proxy”相关文档，要么是旧版错误翻译，要么指向非官方 fork 工具，不建议引入生产环境。
并发卡顿真因：HTTP 请求池 + 镜像限流，不是“二进制锁”
你看到 composer install 卡在 Downloading 或反复超时，不是因为某个“二进制代理进程”被锁住，而是 Composer 客户端并发发请求，撞上了镜像源的 QPS 限制（比如阿里云镜像默认单 IP 5 QPS），触发 429 Too Many Requests 或静默丢包。
CPA Update - Secure CLI Proxy API Maintenance
下载
安全更新和维护 CLI Proxy API（CPA）部署与配置。用于 CPA 镜像升级、配置变更、认证目录兼容修复、上线验证与回滚。适用于用户提到“CPA 更新/升级/配置改了/容器重建/回滚”等场景。
-
composer config -g repos.packagist.org.concurrent-downloads 2是最直接有效的压制手段（推荐值 2，不是 5 或 10） - 该配置仅对 Composer 2.2+ 生效；低于此版本需升级，或改用环境变量
COMPOSER_PARALLEL_DOWNLOADER=2 - 若同时用了私有 Packagist（如 Satis），还需确认其 Nginx 的
limit_req设置是否匹配该并发值
代理配置必须成对出现，缺一不可
公司内网走 NTLM 代理？别指望只设 http-proxy 就能通——Packagist 全量 HTTPS 请求，https-proxy 字段才是关键。填错格式或漏掉它，Composer 就会 fallback 到直连，结果就是 Could not resolve host 或 Connection refused。
- 两条命令必须都执行：
composer config -g http-proxy http://127.0.0.1:3128和composer config -g https-proxy http://127.0.0.1:3128 - 代理地址含特殊字符（如
@或/）必须 URL 编码，例如密码pa@ss/word→pa%40ss%2Fword - NTLM 场景下，必须本地起
cntlm或px中转，让 Composer 连127.0.0.1:3128，而不是直接配域控代理
CI 环境里最容易被忽略的三件事
流水线跑 composer install 慢，往往不是网络问题，而是权限、用户上下文和缓存策略没对齐。
- 宝塔、Jenkins 或 GitHub Actions 默认以
www或runner用户运行，但composer config -g写的是 root 或当前登录用户路径 → 改用项目级配置：composer config repo.packagist composer https://mirrors.aliyun.com/composer/ -
--no-dev --prefer-dist --no-autoloader必须组合使用，否则 autoload 扫描和 dev 包解析会吃掉 40%+ 时间 - CI job 启动前清空
~/.composer/cache，否则旧缓存可能含损坏元数据，导致 SAT 求解器死锁卡在Resolving dependencies
