验证镜像源是否真正写入全局配置的唯一可靠方式是运行composer config -g repo.packagist，输出必须为完整JSON对象（如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}）；若为空、null、https://packagist.org或报错，则配置未生效。

运行 composer config -g repo.packagist 看输出是不是完整 JSON

这条命令是验证镜像源是否真正写入全局配置的唯一可靠方式。输出必须是形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整对象。如果返回空、null、https://packagist.org，或者报错 Could not read .../config.json，说明根本没生效——不是网络慢，是配置压根没落盘。

用 composer config -g --list 检查代理和超时项是否在列

代理和超时类配置容易漏配或写错字段名，composer config -g --list 会列出所有显式设置的全局项。重点关注：

Workflow Decomposer

工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。

下载

• http-proxy 和 https-proxy 必须同时存在，且值都是 http:// 开头（哪怕代理本身走 TLS）
• process-timeout 和 http.timeout 应该有明确数值，比如 0 或 600
• 如果看到 repos.packagist（带 s）而不是 repo.packagist（单数），说明键名写错了，会被完全忽略

执行 composer diagnose 观察网络连接结论

这个命令不改任何东西，但会真实发起 HTTPS 请求测试连通性。关键看最后几行输出：

• 出现 Checking https connectivity to packagist: OK → 实际走的是你配的镜像，不是官方源
• 若显示 Checking https connectivity to packagist: FAIL，但镜像 URL 能被 curl -I 正常访问，大概率是 IPv6 fallback 卡住：用 curl -v https://mirrors.aliyun.com/composer/ 2>&1 | grep "Connected to" 看是否连了 IPv6 地址后挂起
• 提示 WARNING 说 HTTPS is working but HTTP is not，说明 secure-http 配置冲突，可能被项目级 composer.json 覆盖

删掉 vendor/ 和 composer.lock 后跑一次 composer install -vvv

这是最终验真手段。加 -vvv 会打印每一步请求地址：

• 第一行应出现类似 Downloading https://mirrors.aliyun.com/composer/packages.json，而非 packagist.org
• 如果看到 Cloning git@github.com:...，说明它跳过了镜像，直接走 Git —— 这时要检查是否启用了 prefer-source，或包本身强制指定了 VCS 类型
• 过程中卡在 Loading composer repositories 超过 10 秒，基本是 IPv6 fallback 或 DNS 解析问题，跟镜像配置无关

真正容易被忽略的是：配置写对了 ≠ 生效了。缓存、项目级 repositories、CI 用户权限、甚至 ~/.composer/config.json 文件权限（Windows 下常见只读），都会让看似正确的命令变成无效操作。每次改完配置，composer clear-cache 和 composer diagnose 必须连着跑。