PHP开发工具包：Composer中文镜像深度解析！-composer-PHP中文网

直接结论：换镜像必须配对才生效，90%问题源于配置写法错误或作用域错位；正确命令为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，需严格满足键名repo.packagist、type值composer、url以/结尾三要素，缺一即静默失效。

php开发工具包：composer中文镜像深度解析！

直接结论：换镜像不是“配了就快”，而是“配对才生效”——90% 的卡顿、失败、不走镜像，问题不在网络，而在配置写法或作用域错位。

composer config -g repo.packagist 命令必须严格满足三要素

这条命令看似简单，但漏掉任意一个细节就会静默失效，且不报错：

repo.packagist 是唯一合法键名（注意是 repo 单数，不是 repos；也不能写成 packagist.org）
composer 是 type 值，不是可选参数——省略后 Composer 2.0+ 会 fallback 到官方源
https://mirrors.aliyun.com/composer/ 必须用 HTTPS，且末尾斜杠 / 不能少（少斜杠会拼出 /composerpackages.json 导致 404）

正确写法：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
验证是否生效：composer config -g repo.packagist，应输出类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。如果返回空、null 或报 Key 不存在，说明没写进去。

项目级配置比全局更可靠，尤其适合团队和 CI

全局配置写在 ~/.composer/config.json，但「谁在跑命令」决定读哪个文件：

你在终端用 root 执行了 composer config -g，但宝塔后台以 www 用户运行，它读的是 /home/www/.composer/config.json，根本看不到你的配置
CI 脚本里用了 sudo composer config -g，结果写进了 root 配置，而构建容器里实际用的是 runner 用户，照样失效
项目已存在 "repositories": []（数组格式），composer config repo.packagist ... 会直接报错；需先手动改成 "repositories": {}（空对象）再运行

推荐做法：进项目根目录，运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/。它会安全追加到 composer.json 的 repositories 字段，不覆盖已有私有源——前提是原 repositories 是对象结构。

换源后仍卡在 “Loading composer repositories”？先查配置层级

这不是镜像没响应，而是请求根本没发过去。常见原因：

btpanel phpsite 宝塔面板PHP网站

宝塔面板 PHP 网站管理：站点创建、删除、启停、PHP 版本切换、域名管理、SSL证书管理、伪静态管理、数据库管理

下载

项目级 repositories 配置覆盖了全局设置（项目级优先级更高）
composer.json 里写了 "packagist.org": false 或 "packagist": false，彻底关源
镜像服务本身不可达（比如阿里云镜像临时维护）

排查步骤：

运行 composer config -g repo.packagist 和 composer config repo.packagist（无 -g），分别看哪一层在起作用
检查 composer.json 是否存在 "repositories" 字段，尤其留意有没有禁用语句
临时验证镜像是否可达：curl -I https://mirrors.aliyun.com/composer/packages.json，返回 200 OK 才算服务正常