确认当前生效镜像源应运行composer config -g repo.packagist，输出必须是完整JSON（如{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}）；若为空、null或为官方地址，则全局未生效，且需检查项目级repositories是否覆盖及键名是否拼错。
镜像“还原”后下载慢，大概率不是源被切回官方站，而是配置残留、缓存未清或镜像本身已失效——得先确认当前真实生效的源，再验证它是否真的通、真的新。
怎么确认当前生效的 Composer 镜像源
别信记忆或配置文件路径，直接查运行时实际读取的值：
- 运行
composer config -g repo.packagist，输出必须是类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}的完整 JSON；如果为空、null或仍是https://packagist.org，说明全局没配对 - 若项目根目录有
composer.json且含repositories字段，它会完全屏蔽全局配置；此时要改用composer config repo.packagist（不带-g）查项目级设置 - 拼错键名是头号坑：
repos.packagist（多一个 s）会静默失败，composer命令不报错也不生效
为什么 composer config -g 显示镜像，但 install -vvv 还在请求 packagist.org
日志里第一行 Downloading https://packagist.org/... 是铁证，说明镜像根本没加载。常见原因：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 项目
composer.json中"repositories"字段存在（哪怕值是空数组[]），就会强制覆盖全局配置 - URL 末尾漏了
/，例如写成https://mirrors.aliyun.com/composer，Composer 会拼出非法路径导致 fallback - 用了已停服的旧镜像（如
https://packagist.phpcomposer.com），curl 测返回000或Could not resolve host
如何快速验证镜像是否真通、真同步
不能只看 curl -I 返回 200，得测两件事：连得上、数据新。
- 用
curl -o /dev/null -s -w "%{http_code} %{time_total}s" --connect-timeout 5 https://mirrors.aliyun.com/composer/packages.json，理想结果是200 0.324s；000或超 2s 就别用 - 打开浏览器，对比官网包页（如
https://packagist.org/packages/monolog/monolog）和镜像同地址（https://mirrors.aliyun.com/composer/p/monolog/monolog.json），看versions里最新 tag 是否一致 - 镜像状态页可查同步时间戳：
https://mirrors.aliyun.com/composer/status.html；若显示“上次同步 42 分钟前”，而官网已有新版，就是镜像卡住
强制刷新元数据，不是 clear-cache 就够了
composer clear-cache 只删 ZIP 包和 dist 缓存，不影响 packages.json 元数据复用逻辑。Composer 默认 15 分钟内复用本地索引，哪怕镜像已更新也不会重拉。
- Composer ≥ 2.5：用
composer update --refresh，它会丢弃所有缓存的packages.json，强制从当前镜像重拉 - Composer rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer
- 临时调试加
--no-cache -v，看终端输出的真实请求 URL 是否命中你配的镜像域名
最常被忽略的一点：镜像只加速「下载」，不解决「解析依赖」阶段卡顿。如果 Resolving dependencies 持续十几秒，问题在 PHP 内存、xdebug 或 platform 配置，跟镜像无关。
