Composer卡在Downloading的真正原因是配置错误或缓存残留，而非镜像失效；必须确保repo.packagist配置正确（无多余s、type为composer、URL以/结尾且HTTPS）、验证输出为完整JSON、优先使用项目级配置、清除缓存并删除vendor和composer.lock、通过-vvv日志确认请求命中镜像域名。
composer 卡在 Downloading... 不是网络差，是根本没走镜像——配错一个字符就静默回退到 packagist.org，必须立刻验证是否真生效。
为什么 composer config -g repo.packagist 总是不生效
90% 的失败不是因为镜像源挂了，而是命令写错三个硬性点：repo.packagist（不能多 s）、中间的 composer（type 值，漏掉就 fallback）、URL 必须以 / 结尾且用 HTTPS。
-
repos.packagist、repositories.packagist、packagist.org全部无效，Composer 会当没这回事 - 写成
http://mirrors.aliyun.com/composer/或https://mirrors.aliyun.com/composer（缺斜杠）会导致请求路径拼接错误，返回 404 或空响应 - 执行后必须立刻验证：
composer config -g repo.packagist输出应为完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；如果为空、null或仍显示https://packagist.org，说明完全没写进去
项目级配置比全局更可靠，但别用命令覆盖已有 repositories
全局配置在宝塔、CI/CD、Docker 容器里大概率失效——因为它们常以 www 或 runner 用户运行，读不到你 root 或 user 的配置。项目级配置直接写进 composer.json，拉代码即生效。
- 进项目根目录后运行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g），它会自动向repositories数组追加条目，不破坏已有私有源 - 如果项目已有
"repositories": { "my-git": { "type": "vcs", ... } }这类对象写法，命令会把它转成标准数组格式并插入，安全；但若手动编辑，极易因逗号、引号或括号错位导致composer install直接报 JSON 解析错误 - 务必在
composer.json根节点加"packagist.org": false（不是放在repositories里），否则私有源和镜像共存时可能触发冲突
换源后还是卡？先清缓存、删 vendor 和 composer.lock
镜像只加速下载，不清理旧缓存等于白配——composer 会优先读本地缓存里的 packagist.org 元数据，然后尝试从旧地址校验，结果就是卡在 DNS 或 TLS 握手，根本没发请求到镜像站。
- 必须执行：
composer clear-cache - 删掉整个
vendor/目录和composer.lock文件 - 再跑：
composer install --no-cache（禁用缓存强制走新源） - 别保留旧
composer.lock：它记录的是官方源的包哈希，和镜像返回的元数据不兼容，必然报hash does not match
怎么确认真走镜像？看 -vvv 日志里的实际请求 URL
光看 composer config -g repo.packagist 输出正确没用，得亲眼看到网络请求打到了镜像域名。
立即学习“PHP免费学习笔记（深入）”；
- 实测命令：
composer show monolog/monolog -vvv 2>&1 | grep "Downloading" - 日志里必须出现
mirrors.aliyun.com、mirrors.tuna.tsinghua.edu.cn等镜像域名；如果看到packagist.org或repo.packagist.org，说明 fallback 触发了，配置没起作用 - 临时验证也可用：
composer create-project laravel/laravel demo --repository=https://mirrors.aliyun.com/composer/ -vvv，--repository优先级最高，能绕过所有配置干扰
-vvv 看真实请求——这些才是卡住的真正原因。 
