根本原因是Composer默认启用packagist.org兜底源，即使配置国内镜像仍并行请求原站，DNS/TLS失败导致元数据加载阻塞；须先禁用fallback（composer config repo.packagist false）再设镜像，并清缓存验证生效。
为什么composer require会卡在「Loading composer repositories」阶段
根本原因不是网络慢，而是 Composer 默认从 packagist.org 拉取元数据时，反复尝试 HTTPS 连接 + DNS 解析 + TLS 握手失败，尤其在国内环境容易卡在 Resolving dependencies 前的仓库加载环节。这不是包下载慢，是元数据索引同步阻塞。
- 用
composer diagnose可确认是否卡在Loading composer repositories with package information - 执行
composer require -vvv xxx会看到最后停在Reading composer.json of vendor/package (dev-main)类似行，说明正在轮询远程仓库 - 单纯换国内镜像（如阿里云）但没关掉 packagist.org 的 fallback，Composer 仍会并行请求原站，反而加重超时压力
必须关闭 packagist.org 的 fallback 才能生效
只配置镜像地址不够，Composer 默认开启 packagist.org 作为兜底源（fallback），即使你写了 composer config repo.packagist composer https://mirrors.aliyun.com/composer/，它仍会尝试连原站——只要其中任意一个源响应超时或不可达，整个依赖解析就挂起。
- 正确做法是显式禁用默认源：
composer config repo.packagist false - 再设置镜像：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 验证是否生效：运行
composer config --list | grep repo，输出中应只有你配置的镜像 URL，且repo.packagist值为false - 如果项目已有
composer.json中定义了repositories，需手动删掉"packagist": true或整个packagist条目，否则配置文件优先级高于全局 config
镜像选择与稳定性实测对比
阿里云、腾讯云、华为云镜像都可用，但实际表现差异明显。阿里云镜像更新延迟约 5–10 分钟，适合日常开发；腾讯云偶发 404（尤其对 dev 分支 tag）；华为云对含特殊字符的包名（如 @types/*）解析不稳定。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 推荐首选：
https://mirrors.aliyun.com/composer/，兼容性最好，支持完整 metadata 同步 - 临时救急可试清华源：
https://packagist.phpcomposer.com（注意不是官方清华镜像，是第三方维护，但当前可用） - 避免使用已下线源：如
https://packagist.laravel-china.org已停止服务，请求会永久超时 - 若公司内网有私有 Packagist（如 Satis），务必确保其
packages.json文件可被直接 GET 访问，否则 Composer 会卡在Downloading https://xxx/packages.json
require 卡住时的快速诊断和绕过方法
不是每次都要重配镜像。先快速判断是不是锁文件或缓存导致的假性卡死。
- 删掉
composer.lock和vendor/后重试，排除 lock 文件冲突 - 清空 Composer 缓存：
composer clear-cache，某些损坏的 cache 文件会让require在解析阶段无限重试 - 加
--no-plugins参数运行：composer require --no-plugins xxx，排除自定义插件（如hirak/prestissimo）干扰 - 终极绕过：用
composer require --prefer-dist --ignore-platform-reqs xxx，跳过源码克隆和 PHP 扩展校验，加快流程（仅限调试）
镜像配置本身不复杂，真正容易被忽略的是 fallback 行为和 lock 文件残留——这两点不处理，换十个镜像都没用。
