最简可靠的还原方式是执行 composer config -g --unset repos.packagist 并清缓存，但需分三层验证：环境变量 > 项目级 repositories > 全局配置；推荐用覆盖法 composer config -g repo.packagist https://packagist.org 更稳妥，最后通过 composer require --no-install -vvv 抓真实请求确认是否走官方源。
直接执行 composer config -g --unset repos.packagist 并清缓存，是最简可靠的还原方式——但仅当没被环境变量或项目级配置覆盖时才真正生效。
怎么确认当前实际生效的镜像源
别只看 composer config -g 输出。Composer 查源顺序是：环境变量 > 当前项目 composer.json 中的 repositories > 全局配置。必须分三层验证：
- 查环境变量：
env | grep COMPOSER_REPO_PACKAGIST（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows），有输出就说明它在最顶层强制指定源 - 查项目级配置：
composer config repo.packagist（不加-g），输出非空即表示项目自己写了镜像，全局设置已被屏蔽 - 查全局配置：
composer config -g repos.packagist，返回 “Key does not exist” 才算删干净；若仍显示地址，说明--unset没命中字段名
删配置还是覆盖？优先选覆盖
用 composer config -g repo.packagist composer https://packagist.org 覆盖比删更稳。原因有三：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 旧版 Composer（2.2–2.4）删掉
repos.packagist后可能卡在Could not parse version constraint错误，而覆盖写法完全绕过 fallback 判断逻辑 - 字段名易错：
repos.packagist（复数）才是全局镜像字段，repo.packagist（单数）是项目级字段，写错不报错但无效 - 某些脚手架（如老 Laravel 安装器）会写
"repositories": {"packagist.org": false}，这种写法删repos.packagist没用，得手动删整个repositories块
验证是否真走官方源
改完不验证 = 白改。两个关键动作缺一不可：
- 清缓存：
composer clear-cache，否则仍从本地缓存拉旧元数据 - 抓真实请求：
composer require monolog/monolog --no-install -vvv，滚动日志里找Downloading https://开头的行——正确应含https://repo.packagist.org，不是任何镜像域名
如果日志里仍是 mirrors.aliyun.com 或其他镜像地址，说明项目 composer.json 还留着 repositories，得用 composer config --unset repositories 或手动删掉该段。
容易被忽略的细节
Windows 用户若执行 --unset 提示 Permission denied，大概率是杀毒软件锁了 %APPDATA%\Roaming\Composer\config.json；此时需管理员权限运行终端。另外，composer show -p 首行 URL 显示为 https://packagist.org/packages.json 才算真正落地，别信命令回显，信网络请求本身。
