Composer下载慢90%因直连packagist.org导致DNS解析卡、TLS握手超时、首字节延迟高；必须配置国内镜像，且composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/三要素缺一不可：键名严格为repo.packagist（非repos）、type值必须显式写composer、URL须HTTPS且末尾带/，否则静默回退官方源；还需composer clear-cache、删除vendor和composer.lock，并用composer install -vvv | grep "Downloading"验证日志是否出现镜像域名。
Composer下载慢，90%是因为还在直连packagist.org——DNS解析卡、TLS握手超时、首字节延迟高，不是你本地网络差，而是源本身不可靠。必须换国内镜像，且配置必须精准，错一个字符就静默 fallback 到官方源，不报错也不提示。
composer config -g repo.packagist 命令为什么总不生效
这条命令写错任意一个要素，Composer 就会自动退回到https://packagist.org，且无任何警告。
-
repo.packagist是唯一合法键名；写成repos.packagist（多一个s）或mirror，配置直接被忽略 - 中间的
composer是type值，必须显式写出；漏掉它，Composer 2.x+ 无法识别，直接走默认源 - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/packages.json路径，返回 404，然后自动降级 - 必须加
-g；不加只改当前项目composer.json，换目录或换用户就失效 - 不能用
http://协议；Composer 2.2+ 主动拒绝非 HTTPS 源，根本不会发请求
验证是否真走镜像：别只看 config 输出
composer config -g repo.packagist 显示 URL 不等于实际生效。真正判断依据是网络请求是否打到镜像域名。
- 运行
composer install -vvv 2>&1 | grep "Downloading"，日志里必须出现mirrors.aliyun.com或mirrors.tuna.tsinghua.edu.cn才算成功 - 如果还看到
packagist.org或api.packagist.org，说明 fallback 已发生，配置被覆盖或未写入 - 项目级
composer.json中定义了repositories字段，会覆盖全局配置；可用composer config --list和composer config --list --global对比确认
项目级配置比全局更可靠
全局配置依赖~/.composer/config.json，但在宝塔、GitHub Actions、Docker 或 CI 中，实际运行用户常为www、runner或root，配置不可见或不一致。
- 进项目根目录后执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 该命令会自动向
composer.json的repositories字段添加"packagist"条目，不覆盖已有私有源 - 若原
repositories是数组格式（[]），命令会报错；需先手动改为对象格式："repositories": {} - 改完务必删掉
vendor/和composer.lock，再跑composer install --no-cache；否则旧 lock 文件里的哈希与镜像元数据不匹配，报hash does not match
并发下载调高但别过头
Composer 2.1+ 默认启用并行下载，但并发数默认仅 3–6，且极易被低效镜像或旧缓存拖垮。
- 唯一有效的并发控制项是
http-max-concurrent-downloads；parallel-downloads已弃用，设了也不生效 - 全局设为 8 较稳妥：
composer config -g http-max-concurrent-downloads 8 - CI 中临时覆盖可用环境变量：
COMPOSER_MAX_PARALLEL_HTTP_REQUESTS=6 composer install - 别设超过 10：阿里云/腾讯云镜像在并发 >12 时容易返回
429 Too Many Requests；GitHub 源则可能触发403 rate limit exceeded - 注意：并发只作用于「HTTP 包下载阶段」；
Resolving dependencies、dump-autoload等全是单线程，调并发毫无意义
最易被忽略的一点：换镜像后不clear-cache，旧缓存里存着packagist.org的元数据，Composer 会优先读缓存并尝试从旧地址校验——结果就是卡在 DNS 或 TLS 握手，根本没发请求过去。
