直接换阿里云镜像源可解决90%卡顿问题，但配置必须严格满足三要素：键名repo.packagist（单数）、type值为composer、url为https且末尾带/，缺一则静默失效；验证需输出完整json如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
直接换阿里云镜像源就能解决90%的卡顿、超时、找不到包问题，但配置错一个字符就会静默失效——不是镜像不行，是 Composer 根本没读到你写的地址。
composer config -g repo.packagist 为什么总不生效
这条命令看着简单，实际执行时三个硬性条件缺一不可：
-
repo.packagist是固定键名，写成repos.packagist（多一个 s）或packagist.org都无效 -
composer是必须显式声明的type值，不能省略；只写 URL 会被新版 Composer 忽略 - URL 必须是 HTTPS 协议，且末尾带斜杠：
https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌
任一出错，composer config -g repo.packagist 查出来就是空、null 或报 Key not found，但命令本身不报错，你根本不知道配错了。验证是否成功，必须看到类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整输出。
宝塔/CI 环境里全局配置为啥不起作用
全局配置写在 ~/.composer/config.json，但它只对当前用户生效。宝塔后台默认以 www 用户运行，CI 流水线用的是 runner 用户，Docker 构建里甚至没有 ~/.composer 目录——你给 root 配的镜像，它们根本看不到。
更麻烦的是：你在终端用 sudo composer config -g，结果写进了 /root/.composer/config.json，而构建容器里跑命令的是普通用户，照样 fallback 到官方源。
解决办法很简单：进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动安全写入 composer.json 的 repositories 字段，不破坏已有私有源，还能提交 Git，团队和 CI 行为一致。
换镜像后 vendor 还是慢，可能根本没走镜像
常见假象是“已经切了镜像”，但实际请求仍发往 packagist.org。原因通常有两个：
-
composer.json里写了"packagist": false或"packagist.org": false，这会彻底关掉基础源，连php、ext-json这类核心扩展都拉不到 -
composer.lock文件里记录的是旧源的 dist URL，Composer 会优先尝试这个地址；即使镜像已生效，也会先失败一次再 fallback
所以换源后务必做两件事：
- 删掉
vendor/和composer.lock - 运行
composer clear-cache清掉本地缓存 - 再执行
composer install（不是update）重新生成 lock 文件
临时验证某个镜像是否可用，不用改任何配置
想快速测试清华源或华为源是否响应正常？又不想动现有配置？加 --repository-url 参数就行：
composer create-project topthink/think tp-demo --repository-url https://mirrors.tuna.tsinghua.edu.cn/composer/
这条命令只对当次执行有效，不会写入任何配置文件，适合排查网络连通性或对比不同镜像速度。注意 URL 后面同样要带斜杠，且必须是 HTTPS。
真正容易被忽略的点是：镜像源只是第一步，composer.lock 和缓存才是影响后续安装行为的关键；改完配置不清理 lock 和 cache，等于没改。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
