必须先配置国内镜像源再执行composer install，顺序错误会导致卡在downloading；确认是否生效需运行composer config -g repo.packagist，若输出为{"type": "composer", "url": "https://packagist.org"}或无输出，说明未生效，应使用composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/正确配置。
PHP项目装个 composer install 卡在 Downloading https://packagist.org/packages.json 10 分钟不动？不是网络差，是默认源没换——Packagist 官方源对国内用户根本没做 CDN 加速，DNS 解析慢、TCP 建连抖动、TLS 握手失败都可能触发重试风暴。
怎么确认当前用的是哪个镜像？
别猜，直接看配置：
composer config -g repo.packagist
如果输出是 {"type": "composer", "url": "https://packagist.org"} 或压根没输出，说明你还在走官方源。国内主流镜像（阿里云、腾讯云、华为云）都是完整同步 + CDN + HTTP/2 支持，首包响应通常
- 阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://repo.huaweicloud.com/repository/php/
全局设置镜像的正确命令（别用 --add）
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 是唯一推荐写法。注意三点：
立即学习“PHP免费学习笔记（深入）”；
- 必须带
composer这个 type 参数，否则 Composer 会当成自定义仓库处理，后续require可能报Could not find package - 末尾斜杠不能省，
/composer/和/composer是两个不同路径，后者返回 404 - 别用
--add，它会把新源和官方源并存，Composer 默认优先查官方源，卡顿照旧
项目级临时覆盖比全局更安全
团队协作或 CI 环境里，全局改配置容易引发不可预期行为。直接在项目根目录执行：
composer config repo.packagist composer https://mirrors.tencent.com/composer/
这条命令会写入项目下的 composer.json 的 repositories 字段，Git 提交后所有协作者自动生效。CI 构建时也无需额外配置——前提是你的 composer.json 没被 .gitignore 掉。
- 检查是否生效：
composer config repo.packagist（不加-g） - 想清掉项目级配置：
composer config --unset repo.packagist - 某些老旧项目用了
packagist.org的packages.json缓存，换源后首次运行建议加-vvv看真实请求 URL
镜像不是万能解药：这些坑真有人踩
换完镜像还是慢？先别骂厂商。常见硬伤有三个：
-
composer.lock里记录的是旧版本 hash，但镜像只加速下载，不改变包内容校验逻辑。如果 lock 文件里某个包的dist.url还是https://api.github.com/，Composer 仍会直连 GitHub 下 zip 包——这时得配github-oauth或启用COMPOSER_DISABLE_TLSPROXY - 阿里云镜像不支持
dev-main这类分支别名的实时同步，遇到Could not find branch就得切回官方源临时拉一次 - 华为云镜像对私有包（
type: package）支持不稳定，若项目依赖了本地path类型仓库，记得在repositories里显式声明type: path，别指望镜像自动 fallback
最麻烦的是企业内网——有些公司出口防火墙会拦截 mirrors.*.com 域名，这时候得用 IP + Hosts 绑定，或者让运维开白名单。镜像地址本身只是入口，背后链路一环断，全盘失效。
