composer config -g --unset repos.packagist 常失效是因为 Composer 2.x 实际识别 repos.packagist（复数带s），而设镜像用的是 repo.packagist（单数），删错字段则原配置仍生效；漏 -g 或误删 repositories 也会导致失败，验证需执行 composer config -g repos.packagist 看是否报“Key does not exist”。
composer config -g --unset repos.packagist 为什么经常失效
这条命令看似是“一键还原”，但实际常白执行——根本原因是字段名写错。Composer 2.x（当前主流版本）识别的是 repos.packagist（复数、带 s），而设镜像时用的却是 repo.packagist（单数）。删错一个，另一个照常生效。
常见误操作包括：
- 执行
composer config -g --unset repo.packagist→ 实际删的是旧写法，repos.packagist还在 - 漏掉
-g→ 只删当前项目配置，对全局无效 - 执行
composer config -g --unset repositories→ 删的是整个私有源配置块，可能误伤其他仓库
验证是否删干净：运行 composer config -g repos.packagist，应输出 Key "repos.packagist" does not exist 或直接无输出。
确认当前真正生效的镜像源必须查三层
Composer 不会告诉你它“读了哪个配置”，只按固定顺序取第一个匹配项：环境变量 > 项目级 composer.json 中的 repositories > 全局配置。只看 composer config -g 输出，90% 的人会误判。
逐层检查方法：
- 环境变量：
env | grep COMPOSER_REPO_PACKAGIST（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows）；有输出就说明它在最顶层强制指定源，必须先unset或清空 - 项目级：
composer config repo.packagist（不加-g），直接显示当前目录下实际生效的地址 - 全局：
composer config -g repo.packagist和composer config -g repos.packagist都要查，两者可能并存
哪怕全局删干净了，只要项目 composer.json 里还有 "repositories": {...}，它就优先生效，且完全屏蔽全局设置。
还原官方源最稳的操作不是删，而是覆盖
与其纠结删哪个字段，不如直接覆盖为官方地址——兼容性更好，尤其避开 Composer 2.2–2.4 小版本中删配置后出现 Could not parse version constraint 的 bug。
执行：
composer config -g repo.packagist composer https://packagist.org
注意三点：
- 键名必须是
repo.packagist（单数），这是 Composer 1.x/2.x 全版本都认的主源键 - URL 必须以
/结尾（https://packagist.org/✅，https://packagist.org❌），否则路径拼接错误导致 404 - Windows 用户改完需重启终端，否则环境可能缓存旧配置
该命令不会动 repos.packagist 字段，但 Composer 优先读 repo.packagist，效果等同于还原。
验证是否真走官方源不能只看配置，要看网络请求
清缓存和观察真实 HTTP 请求才是唯一可信验证方式。缓存不清，Composer 会继续用旧镜像拉下来的 packages.json 快照，版本信息错乱、包找不到都可能发生。
完整验证步骤：
- 运行
composer clear-cache - 新建空目录，执行
composer init -n && composer require monolog/monolog --no-install -vvv - 滚动日志中找
Downloading https://开头的行——正确应含https://repo.packagist.org，不是任何镜像域名（如mirrors.aliyun.com） - 额外保险：运行
composer show laravel/framework 11.* -vvv 2>&1 | grep "Downloading"，过滤出元数据请求地址
如果仍见镜像域名，说明某层配置或环境变量仍有残留——这时候再回过头查三层，别跳步。
