Composer安装卡在Installing dependencies或Loading composer repositories，主因是packagist.org国内访问不稳定，应优先全局配置阿里云镜像：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并执行composer clear-cache验证生效。
Composer 安装卡在 Installing dependencies 或长时间停在 Loading composer repositories，大概率不是网络问题，而是默认源（packagist.org）在国内访问不稳定或被限速。换国内镜像能立竿见影，但不是所有镜像都可靠，也不是所有项目都能无脑切。
怎么快速切换到可信中文镜像
推荐使用阿里云或腾讯云镜像，它们同步及时、服务稳定，且支持 HTTPS 和 Composer 2.x+ 全功能。执行一条命令即可全局生效：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意：repo.packagist 是配置键名，不能写成 packagist.org 或漏掉 composer 类型声明；-g 表示全局，避免每次进项目都重复配。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 如果只想对当前项目生效，去掉
-g，并在项目根目录运行 - 切换后建议清空缓存：
composer clear-cache，否则可能仍读旧索引 - 验证是否生效：运行
composer config repo.packagist.url，输出应为镜像地址
为什么有些镜像会报错“Invalid repository type”
部分老旧教程推荐的镜像（如某些高校源）只提供 HTTP 镜像或未正确配置 packages.json 接口，导致 Composer 2.x 拒绝加载——它强制要求镜像返回符合 Packagist 协议的元数据结构。
- 错误典型表现：
Invalid repository type: 'composer'或Could not parse version constraint - 根本原因：镜像未实现完整 Composer API，或返回了不兼容的 JSON 格式
- 安全起见，只用阿里云、腾讯云、华为云等明确标注“支持 Composer 2.x”的镜像
- 临时排查：用
curl -I https://mirrors.aliyun.com/composer/packages.json看是否返回 200 + JSON
切换镜像后 composer update 仍慢？检查这三点
镜像只是第一步，真正拖慢安装的常是依赖解析逻辑本身，而非下载速度。
- 项目中存在大量未锁定版本的依赖（如
"monolog/monolog": "^2.0"），Composer 会反复尝试兼容组合——先锁死composer.lock再更新 -
require-dev里有重型工具（如phpstan/phpstan、infection/infection），它们本身依赖极多，可考虑用--no-dev分离安装 - PHP 的
opcache未启用或配置过小，导致 Composer 自身解析耗时翻倍——检查php -i | grep opcache
镜像切换见效快，但别把它当成万能解药。真正卡顿往往藏在 composer.json 的版本约束写法、PHP 扩展缺失或本地 DNS 解析异常里。先换镜像，再看日志，最后动配置——顺序错了，容易白忙活。
