镜像url在不同isp下返回404或超时，根本原因不是镜像挂了，而是被调度到未同步或健康检查失败的cdn边缘节点；验证需重点查看curl响应头x-cache和age值，而非仅依赖http状态码。
同一镜像URL在不同ISP下返回404或超时
这不是镜像挂了，而是你被调度到了一个未同步或健康检查失败的CDN边缘节点。比如广东移动用户访问 https://mirrors.aliyun.com/composer/ 可能落到华南某缓存陈旧的节点，packages.json 还是2小时前的版本；而北京联通用户命中的华北节点已同步完成。
验证方式很简单：curl -I https://mirrors.aliyun.com/composer/packages.json，重点看两个响应头：
-
X-Cache: HIT且Age: 1200→ 缓存已存在20分钟，可能过期 -
X-Cache: MISS或Age: 0→ 当前节点刚拉取，数据最新
别只盯着HTTP状态码——200 OK 不代表数据新，Age > 300 就该怀疑。
换源后仍卡在 Resolving dependencies 阶段
镜像只加速下载（Downloading），不解决元数据解析（Resolving dependencies）阶段的卡顿。这个阶段依赖的是 packages.json 和各 provider-*.json 文件，而它们的加载顺序是串行的，卡一个就全队列阻塞。
实测建议用以下命令判断链路质量：
- 元数据首字节延迟：
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://mirrors.tuna.tsinghua.edu.cn/composer/packages.json - ZIP吞吐测试：
curl -r 0-1048575 -o /dev/null -s -w "%{speed_download}\n" https://mirrors.aliyun.com/composer/provider-laravel~framework.json
每条跑3次取中位数，任一结果超 1.5 秒就排除该镜像——Composer不会并发拉取这些 provider 文件。
hosts绑定后curl正常但composer install仍失败
这是因为 Composer 2.5+ 启动时仍会尝试解析原始域名做校验，即使你绑定了 /etc/hosts，只要系统DNS不通，它就可能卡在初始化阶段。
常见干扰点：
- 项目级
composer.json中存在"repositories"字段，会无提示覆盖全局配置 -
/etc/hosts里残留了旧的packagist.org或镜像域名绑定 - PHP 的
curl.cainfo指向过期证书路径，尤其在 Ubuntu 22.04+/macOS Ventura+ 上
临时绕过：加 -vvv 参数运行 composer install，看实际请求 URL 是否走对了镜像地址。
镜像URL末尾少斜杠导致静默404
这是最隐蔽也最常踩的坑。https://mirrors.aliyun.com/composer（缺斜杠）和 https://mirrors.aliyun.com/composer/（带斜杠）在HTTP层面是两个不同资源，后者才是Composer能识别的合法仓库根路径。
缺斜杠的后果：
- Composer 会拼出类似
/p2/provider-laravel~framework.json的错误路径 - 返回
404 Not Found或 HTML 页面，但不报错，只是无限重试 -
composer config -g repo.packagist输出为空或 null，说明配置根本没生效
确认方式：composer config -g repo.packagist 必须输出完整 URL（含末尾斜杠），否则重执行配置命令。
