答案是composer 2.2+已弃用repo.packagist键名，必须改用repositories.packagist.org并同时配置type和url（末尾带/），且项目级repositories字段会完全覆盖全局配置，还需清缓存并验证真实请求源。
composer config -g repo.packagist 为什么没反应
它根本不是“被覆盖”，而是压根没生效——Composer 2.2+ 已彻底弃用 repo.packagist 这个键名，写进去也静默忽略。你看到命令执行成功，只是因为语法合法，不代表配置被采纳。
真正有效的全局镜像配置必须用：repositories.packagist.org，且需同时设置两个字段：
composer config -g repositories.packagist.org.type composer-
composer config -g repositories.packagist.org.url https://mirrors.aliyun.com/composer/（结尾斜杠/不能少）
漏掉 .type 行、URL 少斜杠、拼成 repos.packagist.org 或 repo.packagist.org，都会导致 Composer 完全不读取该配置，直接 fallback 到 https://packagist.org。
项目级 repositories 字段会彻底屏蔽全局设置
只要你的 composer.json 里出现 "repositories" 字段，哪怕只写了 "repositories": [] 或 "repositories": {}，全局镜像就立即失效——这是 Composer 的硬性优先级规则，不是 bug。
排查方法很简单：
- 在项目目录下运行
grep -A5 '"repositories"' composer.json - 若存在，执行
composer config --unset repositories（注意：不加-g）临时清除 - 再删掉
composer.lock和vendor/目录，否则旧 lock 文件仍会沿用原始源地址
缓存不清，配置等于白设
composer clear-cache 不是可选项，是强制前置步骤。但要注意：它清的是 ZIP 包和部分 JSON，不强制刷新元数据缓存（packages.json 默认 15 分钟不过期）。
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
所以即使配置写对、clear-cache 执行成功，下次 update 仍可能复用过期的元数据，请求发到错误地址。
更精准的做法是：
- Composer ≥ 2.5：运行
composer update --refresh（只丢弃元数据缓存，不删已下载包） - Composer ≤ 2.4：手动删对应缓存路径，例如
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
验证是否真清干净：执行 ls -la $(composer config --global cache-dir)/repo/，应为空或只剩空子目录。
怎么确认当前走的到底是哪个源
别信 composer config 的输出，它只告诉你“写了什么”，不告诉你“正在用什么”。真正起作用的源，得看三处是否一致：
- 查实际生效配置：
composer config -g repositories.packagist.org.url（必须有输出且带结尾/） - 看诊断报告：
composer diagnose中 “Repo:” 行显示的域名 - 盯真实请求：
composer install -vvv 2>&1 | grep "Downloading.*packages.json"，URL 必须含你配的镜像域名
最容易被忽略的一点：Windows 下 Git Bash 和 PowerShell 可能读写不同路径的 config.json（前者读 %APPDATA%\Composer\config.json，后者可能写进 ~/.composer/config.json），改完却查错文件位置。
