最可靠的做法是执行 composer config -g repo.packagist composer https://packagist.org，该命令在 Composer 2.0+ 全版本生效，明确覆盖全局源配置，绕过 fallback 判断，避免删配置导致的失效或错误。
直接执行哪条命令能真正恢复官方源
最可靠的做法是用 composer config -g repo.packagist composer https://packagist.org，不是删配置，而是明确覆盖。这条命令在 Composer 2.0+ 全版本都生效，绕过所有 fallback 判断逻辑，避免旧版（如 2.2–2.4）在 --unset 后卡在 “Could not parse version constraint” 这类错误里。
-
composer config -g --unset repos.packagist看似简洁，但只是删字段；Composer 并不“还原默认值”，它靠字段是否存在来分支——删对了才走官方源，删错或删漏就失效 - 注意键名：必须是
repo.packagist（单数），不是repos.packagist（复数）。写错字段名不会报错，但配置无效，你根本看不到效果 - 如果之前混用过两种写法（比如先设了
repos.packagist，又设了repo.packagist），建议先统一清理：composer config -g --unset repos.packagist和composer config -g --unset repo.packagist都跑一遍
为什么改完命令还是走镜像
因为 Composer 查源顺序是：环境变量 > 项目级配置 > 全局配置。哪怕全局设对了，只要项目根目录的 composer.json 里有 "repositories" 块，它就优先生效。
- 查项目是否自定义源：
grep -A 5 '"repositories"' composer.json（Linux/macOS）或手动打开文件搜repositories - 查当前实际生效的源：
composer config repo.packagist（不带-g），输出如果是阿里云地址，说明项目级配置盖掉了全局 - 临时覆盖项目级设置：
composer config repo.packagist composer https://packagist.org（进项目目录后运行） - 极端情况：检查是否有
COMPOSER_REPO_PACKAGIST环境变量：env | grep COMPOSER_REPO，有就unset COMPOSER_REPO_PACKAGIST
缓存不清理 = 白换源
换源后不运行 composer clear-cache，Composer 仍会读取旧镜像缓存下来的 packages.json 快照，导致 composer update 找不到新包、锁文件错乱、甚至报 Package not found。
- 清完缓存后验证：
ls -la ~/.composer/cache/应为空或只剩空子目录（Windows 是%APPDATA%\Composer\Cache\） - 再跑一次
composer show -p | head -3，能看到真实来自packagist.org的包列表（如composer/composer），才算真正切换成功 - 别信“命令没报错就成功了”——必须观察下载 URL。加
--no-install测试：composer require monolog/monolog --no-install，看输出里元数据请求地址是不是https://repo.packagist.org
误删或删错配置怎么办
Composer 没有 --undo 或历史回滚机制。删错就只剩两个选择：手动修，或重装配置。
- 手动修：打开全局配置文件（Linux/macOS 是
~/.composer/config.json，Windows 是%APPDATA%\Roaming\Composer\config.json），删掉整个"repositories"段，或把"repo.packagist"改成{"type": "composer", "url": "https://packagist.org"} - 重装配置更省事：
composer config -g repo.packagist composer https://packagist.org直接覆盖，比猜删哪个字段安全得多 - 最容易被忽略的一点：如果你用
sudo或切换用户执行命令，改的可能是另一个用户的配置文件，composer config -g -l输出路径就能看出端倪
