Composer原始镜像恢复_解决自定义源导致的问题

先说几个核心判断：Composer 镜像源出问题，最省事的办法其实是直接执行 composer config -g repo.packagist composer https://packagist.org，强行让所有请求都走官方源。这比通过 --unset 删除配置来得更稳，尤其是在 Composer 2.2 到 2.4 这些旧小版本上，不会莫名其妙卡在 Could not parse version constraint 这类报错里。

为什么 composer config -g --unset repos.packagist 有时不生效

这个命令本质上只是在 JSON 文件中删掉一个字段，并不是“重置为默认状态”。实际失效的理由，常见就这几个：

• 字段名写错：必须是 repos.packagist（注意是复数），写成 repo.packagist（单数）的话，系统不会报错，但配置根本没有被移除。
• 旧版 Composer 的 fallback 逻辑有坑：2.2 到 2.4 这些版本，一旦配置被删，fallback 机制可能会直接崩溃，要么卡死、要么报错。
• 项目级配置优先级更高：如果项目下的 composer.json 里本来就有 "repositories" 块，那它的优先级高于全局配置。你删了全局等于白删。它依然会走项目里写死的源。
• 环境变量还在“顽固”覆盖：环境变量 COMPOSER_REPO_PACKAGIST 如果还留着，它会直接覆盖掉全局配置和项目配置，优先级最高。

怎么确认当前真正走的是官方源

不能只看命令有没有执行成功，必须验证两件事：配置确已生效，网络请求的地址确实变了。

• 查当前实际生效的源：运行 composer config repo.packagist（不加 -g）。输出里应该出现 https://repo.packagist.org，而不是 mirrors.aliyun.com 这类镜像域名。
• 看真实请求地址：执行 composer require monolog/monolog --no-install -vvv，在滚动日志里搜索 Downloading https:// 开头的行。URL 必须是 https://repo.packagist.org。
• 检查缓存是否清了：缓存不清理，换源等于白换。Linux/macOS 上执行 ls -la ~/.composer/cache/，Windows 执行 dir %APPDATA%\Composer\Cache\，目录应该是空的，或只剩空子目录。

三层配置覆盖关系必须理清

Composer 查源的顺序是固定且严格的：环境变量 > 项目级配置 > 全局配置。哪怕你全局设得再对，只要其中一层盖住了，就一定不生效。

• 查项目是否自定义了源：Linux/macOS 上运行 grep -A 5 '"repositories"' composer.json，或者直接打开 composer.json 搜 repositories。
• 临时覆盖项目级设置：进项目目录后，执行 composer config repo.packagist composer https://packagist.org，这能强制项目走官方源。
• 查环境变量干扰：Linux/macOS 上运行 env | grep COMPOSER_REPO，Windows 运行 echo %COMPOSER_REPO_PACKAGIST%。如果有输出，直接 unset COMPOSER_REPO_PACKAGIST 或对应方式清除。

最后必须提醒一点：缓存不清，换源等于白换。哪怕配置全对、URL 也正确，composer update 依然可能拉错包或报 Package not found——因为旧镜像的 packages.json 快照还稳稳躺在缓存里。这是最容易被忽略、也最容易让人疯狂怀疑人生的一步。