composer config -g repo.packagist 不生效是因为三个硬性条件未满足：键名必须为单数小写 repo.packagist、中间必须显式指定 type 值 composer、url 必须以 https:// 开头且末尾带 /；验证需输出完整 json 对象，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
composer config -g repo.packagist 命令总不生效？检查这三处硬性条件
配完还是走 packagist.org，不是网络问题，是命令写错——Composer 2.2+ 之后对这三个地方极其严格，错一个就静默回退官方源，且完全不报错。
-
repo.packagist必须是单数、全小写、无额外字符（repos.packagist或packagist.org都无效） - 中间的
composer是type值，必须显式写出，不能省略、不能替换成https或其他字符串 - URL 必须以
https://开头，且末尾必须带/（https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌）
验证是否真写进去了：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，例如：
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}如果返回空、null、报 Key not found，说明根本没配成功。
2026 年实测可用的 Composer 中文镜像地址（HTTPS + 全量同步）
截至 2026 年 7 月，以下三个镜像稳定可用，延迟均控制在 5 分钟内，且强制 HTTPS：
- 阿里云：
https://mirrors.aliyun.com/composer/ - 腾讯云：
https://mirrors.cloud.tencent.com/composer/ - 华为云：
https://mirrors.huaweicloud.com/repository/php/composer/（注意路径含/repository/php/composer/，不是根路径）
已不可用或高风险地址（请立刻停用）：
-
https://packagist.phpcomposer.com（2023 年已下线） -
https://packagist.laravel-china.org（同步不稳定，常卡住） - 任何
http://开头的地址（Composer 2.5+ 强制拒绝 HTTP）
全局配置 vs 项目级配置：什么时候该用哪一种？
全局配置适合个人开发机，但 CI、宝塔、Docker 等多用户环境极易失效——因为 -g 写的是当前 shell 用户的配置，而 Web 服务可能以 www 用户运行。
- 全局配置命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 项目级配置命令（推荐用于团队协作和 CI）：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 项目级配置会自动写入
composer.json的repositories字段，且优先级高于全局配置 - 改完
composer.json后，务必删掉vendor/和composer.lock，再执行composer install，否则旧 dist URL 仍会残留
换源后仍卡在 “Loading composer repositories”？清缓存才是关键
镜像只加速元数据加载和 ZIP 包下载，不解决缓存污染问题。常见现象是日志里仍出现 Downloading https://packagist.org/packages.json，说明本地缓存或 lock 文件还在用旧地址。
- 先运行
composer clear-cache清除本地元数据缓存 - 删除项目下的
vendor/目录和composer.lock文件 - 再执行
composer install -vvv，观察日志中请求的 URL 是否含mirrors.aliyun.com等国内域名 - 若仍失败，可临时加
--repository单次验证：composer install --repository=https://mirrors.aliyun.com/composer/
镜像本身不参与依赖解析，卡在 Resolving dependencies 是约束太宽或 dev 包太多导致的，跟镜像无关——这点最容易被忽略。
