直接执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/可解决90%下载问题，但漏-g、少末尾/或误用repos.packagist均静默失效；须验证composer config -g repo.packagist输出及-vvv日志域名确认生效。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的 Composer 下载卡顿、超时和 404 问题，但漏 -g、少末尾斜杠、用错键名 repos.packagist 中任意一项，都会静默失效——不报错，也不走镜像。
确认 Composer 版本和配置键名是否匹配
Composer 2.0+（包括当前主流的 2.9.6）只认 repo.packagist（单数），repos.packagist 已废弃，设了也无效。
- 查版本：
composer --version，输出含2.开头即为新版 - 验证当前全局配置：
composer config -g repo.packagist，应返回完整 URL 或 JSON 对象；若为空、null或仍是https://packagist.org，说明没生效 - 别手写
~/.composer/config.json—— 容易格式错误；统一用config命令操作
为什么换了镜像还是卡在 Downloading？
项目级 repositories 配置会直接覆盖全局镜像，这是最常被忽略的失效原因。
- 检查是否被劫持：
composer config -l | grep repositories.packagist，如果输出带项目路径，说明composer.json里写了"repositories"字段 - 查看
composer.json顶层是否有"repositories"，尤其注意是否包含"packagist.org": false这类显式禁用项 - 临时绕过所有自定义源验证：
composer install --no-plugins --repository=https://packagist.org，如果这时反而快了，就坐实是项目配置覆盖问题
必须加 -vvv 看真实请求地址
-vvv 不是调试可选项，它是唯一能确认“到底走哪个源”的证据 —— 日志里出现 mirrors.aliyun.com 才算真生效。
- 运行：
composer install -vvv 2>&1 | grep "Downloading"，观察 URL 域名 - 临时测试镜像可用性：
composer create-project laravel/laravel test --repository=https://mirrors.aliyun.com/composer/ -vvv - 不加
-vvv时，即使失败也可能只显示 “Downloading xxx” 而不暴露域名，无法定位问题
换镜像后仍慢？先清缓存，再查本地环境
镜像只加速下载，不解决依赖解析卡顿。如果卡在 Resolving dependencies，和镜像无关。
- 必须执行：
composer clear-cache—— 缓存里还存着旧的packages.json和元数据，Composer 会优先读缓存，哪怕配置已改，它仍试图从旧地址拉校验信息 - PHP 内存不足：默认 128M 不够，临时加
COMPOSER_MEMORY_LIMIT=-1再试 - Xdebug 启用中：会让解析慢 5–10 倍，用
php -d xdebug.mode=off $(which composer) install临时禁用 -
platform配置与实际 PHP 版本不匹配：比如"php": "7.4"却在 PHP 8.2 上运行，触发降级查找逻辑
最容易被忽略的是：换源后不 clear-cache，就等于没换；而没加 -vvv 看日志，就等于没验证。这两步跳过，所有配置都只是幻觉。
