应使用 curl -I 测试镜像真实地址如 https://mirrors.aliyun.com/composer/packages.json 是否返回 200，而非依赖 composer diagnose；同时需用 composer config -g repo.packagist 确认全局配置生效，并通过 composer show -p 观察实际请求域名验证镜像是否真正启用。
curl -I 直接测镜像地址是否返回 200
别信 composer diagnose，它只连 https://packagist.org，跟你配的镜像无关。真正验证镜像通不通，就用 curl -I 打真实地址：
-
curl -I https://mirrors.aliyun.com/composer/packages.json—— 应返回HTTP/2 200 -
curl -kI https://mirrors.aliyun.com/composer/packages.json—— 如果报 SSL 错误，说明证书链被拦截（常见于企业网络） -
ping mirrors.aliyun.com或nslookup mirrors.aliyun.com—— 排查 DNS 解析失败
如果 curl 都超时或 404，换源或换网络比调 Composer 配置更有效。
composer config -g repo.packagist 查当前生效的全局源
这条命令是确认你到底设没设对镜像的最快方式。注意必须带 -g，否则查的是项目级配置，容易误判：
- 输出
{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}→ 镜像已生效 - 输出
{"type": "composer", "url": "https://packagist.org"}→ 没设镜像，走官方源 - 输出空或报错 → 全局没配，或键名写错（比如用了
repo.packagist.org或repos.packagist）
键名错误是 Composer 2.2+ 最常见的失效原因：必须是 repo.packagist（旧版兼容）或 repositories.packagist.org（新版强制），拼错、多字母、少点号都会被静默忽略。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
composer show -p | head -5 真实走一次当前源
composer diagnose 不走实际源，composer show -p 才会发起真实请求，拉取包列表元数据：
- 运行
composer show -p | head -5，观察日志里请求的域名是不是你配的镜像地址 - 如果日志里出现
Downloading http://github.com/...或repo.packagist.org，说明镜像没真正生效 - 该命令不下载 zip 包，速度快，适合快速验证源可用性
它绕过了 diagnose 的硬编码限制，也避开了项目级 repositories 字段的覆盖干扰（只要没在 composer.json 里定义，就走全局配置）。
删 vendor 和 composer.lock 后再试 install
镜像配置改了但 install 还走老地址？大概率是 composer.lock 缓存了旧源信息：
- 执行
rm -rf vendor composer.lock - 再跑
composer install -vvv，看日志中Loading composer repositories那行的 URL 是不是镜像地址 - 如果项目
composer.json里有"repositories"字段，哪怕内容是{"packagist.org": false}，也会完全屏蔽全局镜像——这时得先composer config --unset repositories
很多人卡在这一步：配置明明对了，composer config -g repo.packagist 也显示正确，但 install 日志里还是出现 repo.packagist.org —— 八成是 lock 文件或项目级 repositories 在捣鬼。
