最稳方式是覆盖为https://packagist.org；删错字段、漏清缓存、忽略项目级配置是90%失败根源，实际生效顺序为环境变量＞项目composer.json＞全局配置。
直接还原官方源最稳的方式，不是删配置，而是覆盖为 https://packagist.org；删错字段、漏清缓存、忽略项目级配置，是 90% 失败的根源。
查清楚当前到底在用哪个镜像源
别只信 composer config -g repo.packagist 的输出——它可能被更高优先级的配置盖掉。实际生效顺序是：COMPOSER_REPO_PACKAGIST 环境变量 > 当前项目 composer.json 中的 repositories > 全局配置。
- 查环境变量：
env | grep COMPOSER_REPO_PACKAGIST（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows），有输出就得先 unset - 查项目级源：
composer config repos.packagist（在项目根目录下运行），如果返回阿里云地址，说明项目自己写了源，全局设置完全无效 - 查真实请求地址：运行
composer require monolog/monolog --no-install -vvv，滚动日志里找Downloading https://...这一行，域名必须是repo.packagist.org才算真正切回官方源
删还是覆盖？优先选覆盖，且必须用对键名
Composer 2.x 实际读取的是 repos.packagist（复数，带 s），但很多人设镜像时用的是 repo.packagist（单数）。这两个字段互不干扰，删错一个，另一个还在生效。
- 最可靠操作：执行
composer config -g repos.packagist composer https://packagist.org—— 直接覆盖，不依赖是否存在、不触发 fallback 逻辑 - 如果坚持删：必须用
composer config -g --unset repos.packagist（注意是repos，不是repo），删完立刻清缓存 - 别碰
repositories字段本身：那是放私有源的地方，删了会连企业内部包都拉不到
清缓存和验证缺一不可
改完配置不等于立刻生效，Composer 会缓存元数据（比如 packages.json），旧缓存仍指向镜像域名，install 或 update 会继续走错路。
- 必须运行
composer clear-cache，不是dump-autoload，也不是手动删~/.composer/cache - 验证是否成功：新建空目录，执行
composer init -n && composer show laravel/framework -vvv 2>&1 | grep "Downloading"，输出 URL 应含repo.packagist.org - 如果还失败，检查项目
composer.json是否残留"repositories": { "packagist": { ... } }块，手动删掉或用composer config --unset repositories
最容易被忽略的是项目级 repositories 配置——它会彻底屏蔽全局设置，哪怕你把全局删得干干净净，只要项目 composer.json 里有一行 "packagist": false 或任意自定义 URL，官方源就永远进不来。
