直接执行composer config repo.packagist composer https://mirrors.aliyun.com/composer/即可生效，但缺-g、键名错为repos.packagist、URL末尾无/或漏composer类型值任一都会静默失效；项目级配置写入composer.json更可控，需确保repositories为对象结构、清缓存并重生成composer.lock。
直接执行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/ 就能生效，但漏掉任何一环都会静默失败
这不是网络慢，是根本没走镜像——命令里缺 -g、键名写成 repos.packagist、URL 少末尾 /、或漏掉中间的 composer 类型值，四者任一出错，Composer 都不报错，只 fallback 到 https://packagist.org。
项目级配置比全局更可控，尤其适合 Git 协作和 CI 环境。它会把配置写进当前项目的 composer.json 的 repositories 字段，自动合并而非覆盖（前提是原 repositories 是对象，不是数组）。
-
repo.packagist是固定键名：不能加s，不能大小写混用，不能省略repo.前缀 -
composer是必需的type值：不是注释，不是可选参数，漏掉就等于没配 - URL 必须以
https://开头且末尾带/：写成https://mirrors.aliyun.com/composer会导致请求路径拼成/composerpackages.json，直接 404 - 不加
-g才是项目级：命令在项目根目录下运行，结果写入composer.json，可被 Git 跟踪
验证是否真在用阿里云镜像，别信“好像快了”
靠感觉判断毫无意义。必须查三处：
- 运行
composer config repo.packagist（不加-g），输出应为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} - 运行
composer diagnose，看 “Repo” 行是否显示阿里云地址；若仍是https://packagist.org，说明被项目composer.json中其他repositories配置覆盖了 - 删掉
vendor/和composer.lock，再跑composer install -vvv，日志中所有Downloading行的域名必须含mirrors.aliyun.com
特别注意：composer.lock 文件里硬编码的 dist.url 仍可能指向原始源——哪怕镜像已生效，composer install 仍会先尝试旧地址。必须重生成锁文件才能彻底切换。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
已有 "repositories": {"packagist.org": false} 怎么办
这是常见陷阱：禁用了默认源，却没指定替代源，结果 composer install 直接报 Could not find package。
- 先手动删掉
composer.json中整个"repositories"字段（或至少删掉"packagist.org": false这一项） - 再执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/ - 立即运行
composer clear-cache：否则缓存元数据仍可能触发对packagist.org的请求 - 如果原
repositories是数组（如[{}]），该命令会报错；需先手动转成对象格式（如{}）再试
为什么全局配置在 CI 或宝塔里反而容易出问题
全局配置写在 ~/.composer/config.json，但 CI 流水线、宝塔面板等环境常以不同用户身份运行命令（比如 www 用户），导致实际读取的是另一个用户的配置文件——你配了，但执行命令的进程根本看不到。
- 全局配置无法被 Git 跟踪，新人拉代码后行为不一致
- 多个项目混用时，一个项目改了全局配置，会影响其他项目，引发
composer.lockhash 不一致、部署失败 - 某些脚手架模板（如 Laravel）自带
"repositories": {"packagist.org": false}，会直接屏蔽全局设置 - 项目级配置写进
composer.json，所有人拉代码后composer install行为完全一致，这才是团队协作的真实安全边界
最常被忽略的是缓存残留和 composer.lock 里的 dist URL —— 它们不会因配置变更自动刷新，必须主动清理和重建。
