Composer本身不支持自动镜像切换，必须靠外部控制；composer config -g repo.packagist 失效主因是键名错（如多s）、缺type值“composer”、URL末尾无/，三者任一出错均静默失效，且项目级repositories会完全屏蔽全局配置。
Composer 本身不支持镜像源自动迁移或 fallback 切换，所谓“平滑切换”必须靠外部控制逻辑实现，否则容易卡在 404、超时或静默走错源。
composer
config -g repo.packagist 命令为什么总不生效
最常见原因是三处写错任意一个，就静默失效且不报错：
键名写成
（多了一个 s）—— Composer 内部只认单数形式
漏掉
类型参数：完整命令必须是
，少掉中间的
，2.0+ 版本会 fallback 回官方源
URL 末尾缺
：比如写成
，实际请求会变成
，直接 404
验证是否真生效，别只看命令有没有报错，要跑：
，输出必须是类似
这样的完整 JSON。
项目级 repositories 字段会彻底屏蔽全局配置
只要项目根目录下的
里定义了
（哪怕只是空对象
或
），全局设置就完全不生效。
排查方法很简单：
运行
看是否存在
临时绕过：执行
（注意没
）
不想删？可覆盖写入：
，它会自动合并进
对象
这个行为不是 bug，是 Composer 的明确优先级规则：项目级 > 全局配置。
CI/CD 中镜像切换失败的隐藏原因
即使
执行成功，在 CI 流水线里仍可能继续连旧源，因为：
没执行，本地缓存的
还指向旧域名
Docker 构建时复用了旧的
或
目录
某些 CI 镜像预装了 Composer，但
指向了非预期路径（如 Windows 下 Git Bash 读
而非
）
更稳妥的做法是：在 CI 脚本里统一用环境变量临时指定，比如
，避免依赖任何持久化配置。
Composer ≥2.2 的 repositories.packagist.org 并不等于 fallback
有人看到文档里有
就以为能配多个源做主备，其实不是：
它只是
的新键名，兼容性写法；设两个同类型源仍会报
所谓 “fallback” 是指当镜像源返回 404（比如包未同步）时，Composer 会自动回退到官方源查一次 —— 但这和“镜像挂了自动切另一个镜像”无关
真要做主备，得自己写 shell 脚本：先
，失败则
最容易被忽略的是：
元数据缓存比你想象中顽固，哪怕源地址改对了，不
，请求照样发往旧域名。
repo.packagistrepos.packagistcomposercomposer config -g repo.packagist composer https://mirrors.aliyun.com/composer/composer/https://mirrors.aliyun.com/composerhttps://mirrors.aliyun.com/composerpackages.jsoncomposer config -g repo.packagist{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}composer.json"repositories"{}{"packagist.org": false}grep -A5 repositories composer.jsoncomposer config --unset repositories-gcomposer config repo.packagist composer https://mirrors.ustc.edu.cn/composer/repositoriescomposer config -gcomposer clear-cachepackages.json~/.composer/cachevendorCOMPOSER_HOME%APPDATA%\Composer\config.json~/.composer/config.jsonCOMPOSER_REPO_PACKAGIST=https://mirrors.cloud.tencent.com/composer/ composer installrepositories.packagist.orgrepo.packagistInvalid repository typecurl -I https://mirrors.aliyun.com/composer/packages.jsoncomposer config -g repo.packagist composer https://mirrors.cloud.tencent.com/composer/packages.jsonclear-cache