最快速有效的办法是执行composer config -g repo.packagist composer https://packagist.org全局覆盖源地址，它兼容所有>=2.0版本、绕过fallback逻辑，比unset更可靠。
直接执行命令就能恢复官方源
镜像源挂了，最快速有效的办法就是把 Composer 的包源地址强制设回 https://packagist.org。别折腾删配置、重装或查日志——只要网络能通这个地址，一条命令就解决问题：
-
composer config -g repo.packagist composer https://packagist.org（全局生效，推荐） - 如果只想修当前项目，进项目目录后运行：
composer config repo.packagist composer https://packagist.org
这个命令不是“删除”镜像配置，而是明确覆盖它。相比 composer config -g --unset repos.packagist，它更可靠：旧版本 Composer（如 2.2–2.4）在 unset 后可能 fallback 失败，报 Could not parse version constraint 或干脆卡住；而直接设 URL 能绕过所有 fallback 逻辑，兼容所有 >=2.0 版本。
为什么执行完还是走镜像？检查三层覆盖关系
执行了命令却没生效，大概率是被其他配置“盖掉了”。Composer 查源顺序是：环境变量 > 项目级配置 > 全局配置。哪怕你全局改对了，只要项目 composer.json 里有 "repositories" 块，它就优先生效。
- 查项目是否自定义了源：
grep -A 5 '"repositories"' composer.json - 查当前实际生效的源：
composer config repo.packagist（不带-g） - 如果输出仍是阿里云或腾讯云地址，删掉
composer.json里的整个"repositories"段，或临时用composer config repo.packagist composer https://packagist.org覆盖它 - 极端情况：检查是否有
COMPOSER_REPO_PACKAGIST环境变量（env | grep COMPOSER_REPO），有就unset COMPOSER_REPO_PACKAGIST
缓存不清理，等于白换源
换源后不清理缓存，Composer 会继续读取旧镜像下载下来的 packages.json 快照，导致 composer update 拉错版本、找不到包，甚至锁文件更新失败。
- 必须执行：
composer clear-cache - 验证是否清干净：
ls -la ~/.composer/cache/应该为空或只剩空目录 - 再跑一次
composer show -p | head -3，能看到真实包列表（比如composer/composer），才说明源和缓存都正常了
换回官方源后还是慢？别只盯镜像
即使确认走的是 https://packagist.org，install/update 还卡在 “Downloading https://packagist.org/packages.json” 阶段，问题往往不在源本身，而在网络中间环节：
- DNS 解析异常：
dig packagist.org +short或curl -I https://packagist.org看是否能通 - Gzip 响应处理失败（常见于某些代理或防火墙）：加
--no-cache强制跳过压缩协商，例如composer require monolog/monolog --no-cache - 元数据过大导致超时：可临时用
composer config -g repos.packagist composer https://packagist.org显式声明 type，避免自动降级逻辑干扰
真正生效的永远是最终被读取的那个 repo.packagist 值，它可能藏在环境变量、项目配置、全局配置三处任意一层——光看命令是否执行成功没用，得实测 composer show -p 和 curl -s https://packagist.org/packages.json | head -c 100 才算闭环。
