答案是composer慢主因非镜像失效而是配置错误、缓存未清或链路不全：键名必须为repo.packagist（非repos）、type值必填composer、url须含末尾/，三者缺一即静默回退官方源；需验证config输出及-vvv日志确认镜像路径，且重装前须删vendor与composer.lock以更新dist.url。
packagist.org 默认源在国内访问极不稳定，不是网速慢，而是 DNS 解析慢、TLS 握手卡顿、首字节延迟常超 300ms，元数据请求失败率高。不配镜像，composer install 卡在 Loading composer repositories 或报 could not find package、Operation timed out 是常态。
镜像配置不是“可选项”，而是让依赖安装从“玄学等待”变成确定性操作的前提。
为什么 composer config -g repo.packagist 命令总像没生效
它不报错，但实际仍连 packagist.org——根本原因是三个硬性条件漏掉任一就静默 fallback：
-
repo.packagist键名必须一字不差：写成repos.packagist、repository.packagist或mirror全部无效 - 中间的
composer是type值，小写，不可省略；漏掉它，Composer 就当这行配置不存在 -
URL必须是 HTTPS 且末尾带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json导致 404）
验证是否真写进去了？运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null、或仍是 https://packagist.org，说明根本没写成功。
项目级配置为什么比全局更可靠
只要项目根目录下 composer.json 里定义了 repositories 字段（哪怕只写了 []），全局配置就会被完全跳过——不是优先级低，是压根不读。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 全局配置只写入
~/.composer/config.json，CI 流水线、宝塔面板（www用户）、Docker 容器里往往读不到它 - 项目级配置写进
composer.json的repositories字段，Git 提交后，谁拉代码、在哪跑，都走同一套源 - 执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g）会自动追加到repositories数组首位，不破坏已有私有源 - 改完必须删掉
vendor/和composer.lock，再跑composer install——update不行，它会沿用旧 lock 文件里的 dist URL
换源后还是卡在 Resolving dependencies？和镜像无关
镜像只加速元数据加载和 ZIP 包下载，不参与依赖解析。卡在这里基本是 composer.json 写法或环境问题：
- PHP 版本约束太宽，比如
"php": "^7.4 || ^8.0"，让 Composer 尝试遍历大量不兼容版本 -
require-dev里塞了太多工具链（如phpunit、phpstan），大幅增加解空间 - 用了已废弃的
fxp/composer-asset-plugin（常见于老版 Yii2），它绕过 Composer 镜像机制，直连 Bower/NPM 源
这类问题换任何镜像都无效，得收紧约束、拆分 dev 包、或升级到原生 asset 管理方案。
真正容易被忽略的是：镜像同步有 5–30 分钟延迟，新 tag 发布后不会秒级生效；provider-*.json 缺失时 Composer 会 fallback 到全量 packages.json（20+ MB），内存暴涨、解析变慢——这不是算法问题，是兜底逻辑被触发。
