composer config -g repo.packagist用于全局配置Composer默认包仓库地址，将请求从官方packagist.org重定向至指定国内镜像（如阿里云https://mirrors.aliyun.com/composer/），仅影响元数据查询环节，不修改项目composer.json或私有源配置。
国内用 Composer 装包慢、超时、卡在 Downloading、甚至报 Connection timed out，基本不是你网络差，而是没配对镜像源，或者配了但根本没生效。
composer config -g repo.packagist 是干啥的？
这条命令直接改 Composer 全局配置里的默认仓库地址，把原本指向 https://packagist.org 的请求，重定向到你指定的国内镜像站（比如阿里云）。它不碰项目里的 composer.json，也不影响私有仓库配置，只管“找包信息”这一步。
常见错误现象：
- 执行完命令没反应，再查还是空或显示官方源 → 没加
-g（漏了全局标记） - 查出来是
{"type": "composer", "url": "https://packagist.org"}→ 配置失败或被其他配置覆盖 - 项目里
composer install日志里仍出现packagist.org域名 → 项目级配置优先级更高，得进项目目录再跑一次不带-g的命令
为什么删 composer.lock 和 vendor/ 才能提速？
镜像只加速「获取包元数据」和「下载 dist 包」两个环节。composer.lock 里存的是上次解析出的完整下载地址，如果它记录的是 GitHub 原始 zipball 地址（如 "url": "https://api.github.com/.../zipball/..."），Composer 就会跳过镜像直连 GitHub —— 这时候换源完全无效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
所以首次切换镜像后必须：
- 运行
composer clear-cache清掉旧缓存（尤其之前用过失效源如phpcomposer.com） - 删除项目根目录下的
composer.lock文件 - 删除
vendor/目录 - 再执行
composer install -vvv，盯着日志里是否出现mirrors.aliyun.com或对应镜像域名
哪些情况镜像根本不起作用？
镜像不是万能加速器，它只对 Packagist 官方索引的 PHP 包有效。以下场景它插不上手：
- 依赖里写了
"type": "package"或"type": "vcs"，且url指向 GitHub/GitLab 私有库 → Composer 会直接 clone 或下载 API 返回的原始链接 -
composer.json中显式声明了repositories，且其中某个源类型为vcs或package→ 镜像会被绕过 - 安装含
ext-*的扩展（如ext-redis），实际走的是phpize+ 编译 → 慢在本地编译，和网络无关 - 包本身用了
dist+source双模式，但composer.lock锁死的是source分支 → 即使配了镜像，仍会 git clone
阿里云、腾讯云、清华源，怎么选？
2026 年实测下来，差异不在“能不能用”，而在同步时效和稳定性边界：
- 阿里云：
https://mirrors.aliyun.com/composer/—— 全量同步最稳，延迟通常 - 腾讯云：
https://mirrors.cloud.tencent.com/composer/—— 对 Laravel 生态新包响应更快，比如刚发版的laravel/framework补丁，有时比阿里云早 1–2 分钟可见 - 清华源：
https://mirrors.tuna.tsinghua.edu.cn/composer/—— 带宽大，适合一次性装几十个大包（如含前端构建工具的 Laravel 包），但偶发同步延迟（尤其凌晨 2–4 点）
别用已停更的 packagist.phpcomposer.com，2025 年底起大量包返回 404；也别信某些博客里写的“自动检测最佳源”，实际就是轮询，反而增加失败概率。
