Composer下载卡在Downloading的根本原因是未正确配置镜像源，必须严格满足三要素：键名repo.packagist、type值composer、URL以https://开头且末尾带/，否则静默回退官方源；还需清缓存、删vendor和composer.lock后重装。
Composer下载卡在Downloading，不是网络差，是没走镜像
默认直连 packagist.org 时，DNS 解析慢、TLS 握手常超 5 秒、首字节延迟动辄 10+ 秒，甚至直接返回 503 或 Connection timed out。镜像源（如 https://mirrors.aliyun.com/composer/）在国内机房部署，物理距离近、CDN 覆盖广、证书预加载成熟——这些不是“加速”，而是绕过根本性链路瓶颈。
镜像配置三要素漏一即失效：键名、type、末尾斜杠
执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 这条命令，必须同时满足：
-
repo.packagist是唯一被识别的键名，写成repos.packagist或repositories都静默忽略 - 中间的
composer是type值，不是注释或可选参数；漏掉它，配置变成纯字符串，Composer 直接 fallback - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404
验证是否生效，只看 composer config -g repo.packagist 输出：必须是完整 JSON 对象或至少是该 URL 字符串，空、null、或仍是 https://packagist.org，说明根本没写进去。
项目级配置覆盖全局，且删 vendor 和 lock 才真生效
只要项目根目录的 composer.json 里有 repositories 字段（哪怕只是 "repositories": []），全局镜像就完全不生效。此时需：
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 手动删掉
vendor/和composer.lock——因为composer.lock里存的是旧源下的 dist URL，不删它，composer install仍按老地址拉包 - 只跑
composer install，不要用update，让 Composer 从头解析依赖并生成适配新镜像的 lock 文件
CI/CD、Docker、宝塔里镜像不生效，本质是用户上下文错位
GitHub Actions、GitLab CI、宝塔面板的 www 用户、Docker 容器里的非 root 用户，都读不到你本地终端用户的全局配置。解决方案分场景：
- CI 脚本中：先执行
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，再composer install - Docker 构建：在
Dockerfile的RUN指令里写入该命令，确保镜像层固化配置 - 宝塔面板：确认 PHP 运行用户（通常是
www），用该用户身份执行composer config -g，或改用项目级配置避免权限问题 - 临时调试：加
--repository-url=https://mirrors.aliyun.com/composer/参数强制指定，但create-project不支持该参数，得提前配好
最易被忽略的是缓存残留：换镜像后不执行 composer clear-cache，旧缓存里的 packages.json 仍指向官方源，Composer 会继续用它查 provider 列表——表面换了源，实际还在回源请求。
