Composer配置未生效主因是项目级repositories优先级高于全局配置，需检查composer.json中是否硬编码旧源并执行composer config --unset repositories；验证方式为strace抓包或curl测试返回200。
镜像配置写了，composer install 还是慢得像在等包邮——说明它根本没走你配的地址，不是“慢”，是“没生效”。
为什么 composer config -g 显示配置了却没用
Composer 的配置优先级是：项目级 repositories > 环境变量 COMPOSER_REPO_PACKAGIST > 全局配置。哪怕你 config -g 写得再准，只要项目根目录 composer.json 里有 "repositories" 字段，它就会直接忽略全局镜像。
- 运行
grep -A 5 '"repositories"' ./composer.json查看是否硬编码了旧源（比如已下线的https://packagist.phpcomposer.com） - 确认输出中没有
"type": "composer", "url": "https://..."这类有效条目；如果有，且 URL 不带末尾/（如https://mirrors.aliyun.com/composer），就一定会 404 - 临时清掉项目级源：
composer config --unset repositories，再试一次composer install
怎么验证镜像地址真正在被请求
别信 config --list 的输出，要看到真实网络行为。用 strace（Linux/macOS）或 tcpdump（Windows 可用 Wireshark）抓包最直接：
-
strace -etrace=network composer install 2>&1 | grep 'connect'—— 如果看到connect(3, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("114.114.114.114")})这类指向国外 IP 的连接，说明根本没走镜像 - 更轻量的方法：
curl -I https://mirrors.aliyun.com/composer/packages.json，必须返回HTTP/2 200；若返回301或卡住，说明 DNS、证书或镜像本身异常 - CI 环境（GitHub Actions/GitLab CI）默认不继承本地全局配置，必须在 workflow 文件里显式写入镜像命令，否则永远走官方源
composer clear-cache 后还是卡在 Loading composer repositories
缓存清理只是删掉 ~/.composer/cache/ 下的文件，不影响 Composer 解析源地址的逻辑。真正卡住的环节常在 TLS 或 DNS 层：
- 企业网络可能拦截非标准证书链的 HTTPS 请求，
curl -kI https://mirrors.aliyun.com/composer/packages.json若能通但带 SSL 错误，就是证书问题 - 某些镜像（如清华源）公网访问会触发人机验证，返回 HTML 页面而非 JSON，导致 Composer 解析失败；生产环境建议换阿里云或腾讯云源
-
composer diagnose会检查配置合法性，但它不验证连通性；真正有效的诊断是：删vendor/和composer.lock，再跑composer install -v，看 verbose 输出里第一个 HTTP 请求发往哪个域名
为什么换镜像后仍报 404 Not Found
404 不等于网络不通，而是 Composer 找到了源，但源里没有你要的包——常见于镜像同步延迟、包名拼写错误，或包已被下架：
- 先手动访问
https://packagist.org/packages/your-vendor/your-package，确认包存在且大小写完全匹配（monolog/monolog✅，Monolog/monolog❌） - 如果页面能打开，点 “Versions”，确认你要的版本（如
dev-main）是否列出；很多项目已废弃dev-master - 阿里云、腾讯云镜像不代理 Git 克隆，只接管元数据请求；若报错出现在
Cloning into阶段，换镜像无用，得调 Git 超时或换 SSH 源
最常被忽略的一点：镜像 URL 必须带末尾斜杠，少一个 / 就会 404；而 composer config -g 命令不会校验这个格式，它照单全收，然后静默失效。
