直接执行composer config -g repo.packagist composer https://packagist.org即可强制全局使用官方源，比--unset更可靠，尤其在composer 2.2–2.4中可避免fallback失败；需配合composer clear-cache，并检查项目级repositories配置、环境变量及实际请求url。
直接执行 composer config -g repo.packagist composer https://packagist.org 就能强制走官方源，比删配置更稳——尤其在 Composer 2.2–2.4 小版本里，--unset 有时会 fallback 失败导致 update 卡住或报 Could not parse version constraint。
为什么 composer config -g --unset repos.packagist 不总管用
这个命令只删掉 repos.packagist 字段，但 Composer 实际查源顺序是：环境变量 > 项目级配置 > 全局配置。哪怕全局删干净了，只要当前项目 composer.json 里还留着 "repositories" 块，它就优先生效。
- 检查项目是否覆盖：运行
composer config repos.packagist（不加-g），如果输出镜像地址，说明项目级配置还在起作用 - 旧项目可能混用两种写法：
repo.packagist（单数）和repos.packagist（复数），得分别删：composer config -g --unset repo.packagist和composer config -g --unset repos.packagist - 某些脚手架（如老版 Laravel 安装器）会写
"repositories": {"packagist.org": false}，这等于关源又没给替代，删repos.packagist没用，得整个删掉"repositories"字段
怎么确认当前真正生效的源地址
别信 config -g 输出，要看实际请求域名。最可靠方式是加 -vvv 观察元数据下载 URL：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer require monolog/monolog --no-install -vvv - 在日志里搜
Downloading或Loading，找到类似Downloading https://repo.packagist.org/packages.json的行——这才是真实生效的源 - 如果看到的是
mirrors.aliyun.com或mirrors.cloud.tencent.com，说明某层配置还在干扰 - 顺手检查环境变量：
env | grep COMPOSER_REPO（Linux/macOS）或echo %COMPOSER_REPO_PACKAGIST%（Windows）
clear-cache 不是可选项，是必做动作
缓存不清，Composer 仍会读取旧镜像缓存下来的 packages.json 快照，结果就是 update 找不到新包、锁文件错乱、甚至报 Package not found。
- 运行
composer clear-cache后，检查缓存目录是否清空：ls -la ~/.composer/cache/（Linux/macOS）或dir %APPDATA%\Composer\Cache\（Windows）应为空或只剩空子目录 - 清完缓存再跑一次
composer show -p | head -3，能看到来自composer/composer这类包，才算切换成功 - 注意：清缓存对源配置本身完全无感，它只删
~/.composer/cache/下的内容；删了整个~/.composer/目录也没用，因为 Composer 会自动生成默认配置——除非你设了环境变量
最容易被忽略的一点：某些 IDE（比如 PHPStorm）会在项目设置里偷偷注入镜像源，改完配置后不重启 IDE，它依然按旧设置发请求。
