最稳妥的做法是用 composer config -g repo.packagist composer https://packagist.org 覆盖为官方地址，而非删除配置；需按环境变量＞项目级＞全局顺序排查实际生效源，并清理缓存与 composer.lock。
直接还原官方镜像源，最稳妥的做法不是“删配置”，而是用 composer config -g repo.packagist composer https://packagist.org 覆盖为官方地址。删字段容易漏掉复数/单数变体、环境变量或项目级残留，反而导致行为不可控。
确认当前实际生效的镜像源
Composer 查源顺序是：环境变量 > 项目级 composer.json > 全局配置。只看 composer config -g repo.packagist 输出会误判。
- 查项目级实际生效值：
composer config repo.packagist（不加-g） - 查全局配置：
composer config -g repo.packagist - 查环境变量（Linux/macOS）：
env | grep COMPOSER_REPO_PACKAGIST；Windows：echo %COMPOSER_REPO_PACKAGIST% - 验证真实请求地址：
composer require monolog/monolog --no-install -vvv，滚动日志里找Downloading https://开头的行——正确应含repo.packagist.org
覆盖比删除更安全可靠
旧版本 Composer（尤其是 2.2–2.4）在删掉 repo.packagist 后可能 fallback 失败，卡在 Could not parse version constraint。覆盖写入能绕过所有解析逻辑，且兼容所有 2.x 版本。
- 全局切回官方源：
composer config -g repo.packagist composer https://packagist.org - 仅当前项目切回：
composer config repo.packagist composer https://packagist.org - 键名必须是
repo.packagist（单数），不是repos.packagist或repositories；写错不报错，但配置无效 -
composer是必需的 type 值，不能省略；URL 必须以/结尾，否则请求路径拼接错误
缓存和 lock 文件必须清理
composer.lock 文件硬编码了包的 dist.url 和哈希值，哪怕镜像已改，composer install 仍会优先尝试旧地址，导致校验失败或 fallback。
- 执行
composer clear-cache清除本地元数据缓存 - 删除
vendor/目录和composer.lock文件 - 再运行
composer install -vvv，观察日志中所有Downloading行是否都指向repo.packagist.org - CI/CD 中尤其要注意：构建用户与配置用户不一致（如 root 配了，但 runner 以 www-data 运行），需在脚本开头显式重置一次
最容易被忽略的是三层覆盖关系和 composer.lock 的强绑定行为——改完配置不清理缓存和 lock 文件，等于没改；没检查环境变量和项目级 repositories，等于在盲区操作。
