必须换镜像源，因cURL error 28超时主因是直连packagist.org导致DNS慢、TLS握手失败或首字节延迟高；应执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/并清缓存，确保-vvv日志中出现mirrors.aliyun.com路径。
必须换镜像源，不是“建议”，是解决超时的刚性前提。 Composer 卡在 cURL error 28、Resolving dependencies 后长时间无响应、或下载速度为 0 B/s，90% 以上都源于仍在直连 packagist.org——DNS 解析慢、TLS 握手失败、首字节延迟高，和你本地网速无关。
确认当前用的是哪个镜像源
运行：composer config -g repo.packagist
输出必须是完整 HTTPS URL，例如：https://mirrors.aliyun.com/composer/。如果显示 null、空值、或仍是 https://packagist.org，说明配置未生效。
- 常见拼错：
repos.packagist（多一个s），Composer 会静默忽略 - 旧版 Composer（1.x）不识别
repo.packagist，需改用：composer config -g repos.packagist '{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}' - URL 末尾漏了
/，部分版本会拼接出错，导致 404
全局配置阿里云镜像（最稳推荐）
执行这条命令即可立即生效，无需重启终端：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
- 必须带上
composer这个type值，不能省略 - 阿里云同步及时、CDN 覆盖广；已停更的
packagist.laravel-china.org（2025 年底下线）和packagist.phpcomposer.com不再可靠 - 设完立刻清缓存：
composer clear-cache，否则旧元数据仍在缓存中，Composer 仍会尝试从旧地址拉取
验证是否真走国内镜像
光看 config 输出不够，要亲眼看到请求发到了镜像域名：composer install -vvv 2>&1 | grep "Downloading"
- 日志里必须出现类似
mirrors.aliyun.com或mirrors.huaweicloud.com的路径才算真正生效 - 如果还看到
packagist.org，说明 fallback 了——检查项目级composer.json中是否定义了repositories，它会覆盖全局配置 - 临时绕过所有自定义源测试：
composer install --no-plugins --repository=https://packagist.org，如果变快，说明本地repositories配置有问题
代理与 TLS 相关坑点
若你在公司内网或 CI 环境中使用代理，注意：
只配 http.proxy 一定失败。Composer 对 HTTP 和 HTTPS 请求走两套独立路由，所有包仓库均走 HTTPS，仅配 http.proxy 会导致 HTTPS 请求静默直连，卡在 Loading composer repositories 或反复报 cURL error 28。
- 必须同时设置：
composer config -g http-proxy http://proxy.example.com:port和composer config -g https-proxy https://proxy.example.com:port - 某些老旧系统（如 CentOS 6、旧 Jenkins slave 镜像）根证书库太老，访问阿里云镜像会提示
SSL certificate problem，需升级：sudo update-ca-certificates（Debian/Ubuntu）或sudo yum update ca-certificates（CentOS/RHEL） - 镜像只加速「下载」，不解决「依赖解析」本身慢的问题——如果卡在
Resolving dependencies，换镜像完全无效，那是 PHP 环境或composer.lock结构问题
