还原官方镜像核心是清除环境变量、项目级、全局三层覆盖配置并清缓存，因Composer无自动fallback机制；生效顺序为环境变量＞项目composer.json＞全局config.json，且必须用composer clear-cache验证真实请求地址。
报错后还原原厂镜像，核心不是“回滚”，而是清除所有覆盖官方源的显式配置 + 清掉缓存。Composer 没有“自动恢复”机制，只要某层配置（环境变量、项目级、全局）指定了非官方地址，它就会坚持用那个地址——哪怕请求 404 或超时，也不会 fallback 到官方源。
查清当前真正生效的镜像地址
别信 composer config -g 的输出，它只看全局。实际生效顺序是：环境变量 > 项目 composer.json > 全局 config.json。
- 运行
composer config repo.packagist.org（不加-g），它会合并三层配置并返回真实值；若报错Could not find repository 'packagist.org'，说明没配任何镜像，正在直连官方源 - 检查环境变量：
echo $COMPOSER_REPO_PACKAGIST（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows），有输出就说明它在最顶层强制指定源 - 进项目根目录后运行
grep -A 5 '"repositories"' composer.json（Linux/macOS），看是否残留了"packagist": { "url": "..." }这类块
删配置必须对准字段名和作用域
Composer 2.x 实际读取的是 repos.packagist（复数、带 s），但设置镜像常用的是 repo.packagist（单数）。这两个字段完全独立，删错一个等于白干。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 删全局镜像：必须用
composer config -g --unset repos.packagist（注意是repos，不是repo） - 删单数字段（常见于老教程）：补一句
composer config -g --unset repo.packagist - 漏
-g？命令只删当前项目composer.json里的repositories字段，对全局无效 - 删
repositories整个字段？危险——可能误删私有源配置，只动repos.packagist或repo.packagist
覆盖比删除更可靠，尤其 Composer 2.2–2.4 小版本
某些旧版 Composer 在删掉 repos.packagist 后，会卡在 Could not parse version constraint 错误里。直接覆盖为官方地址反而更稳。
- 全局覆盖（推荐）：
composer config -g repo.packagist composer https://packagist.org（注意是repo单数 +composer类型前缀 + 末尾无斜杠） - 项目级覆盖：
composer config repo.packagist composer https://packagist.org（不加-g） - URL 必须带
composer类型前缀，写成https://packagist.org或https://repo.packagist.org都无效
缓存不清 = 配置白改
即使配置已更新，Composer 仍会从本地缓存里读 packages.json 快照，导致 composer update 找不到包、版本解析错乱、甚至锁文件写入错误地址。
- 改完配置后立刻执行：
composer clear-cache - 验证是否真走官方源：
composer require monolog/monolog --no-install -vvv 2>&1 | grep "GET https"，日志里出现的 URL 前缀必须是https://repo.packagist.org - Windows 用户若提示
Permission denied，可能是杀软锁了%APPDATA%\Roaming\Composer\config.json，换管理员权限终端重试
最容易被忽略的是环境变量和项目级 repositories 块里藏的 "packagist.org": false 这种禁用写法——它不指向镜像，而是直接关掉默认源，删全局配置毫无意义，必须手动打开或覆盖。
