命令生效需同时满足三个条件：键名必须为repo.packagist、type值必须为composer、url须以https://开头且末尾带/；否则静默回退官方源，且无报错提示。
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就能解决 90% 的下载延迟问题，但漏 -g、少末尾 /、写错键名 repo.packagist 中任意一项，都会静默失效——不报错，也不走镜像。
为什么命令总不生效？三个硬性条件缺一不可
Composer 2.x（当前主流版本）对配置格式极其敏感，写错就回退到官方源，且无提示：
-
repo.packagist是唯一合法键名：写成repos.packagist（多一个 s）、packagist（少repo.）或mirror都无效 - 中间的
composer是必填的type值，不是可选参数，也不能替换成https或留空 - URL 必须以
https://开头，且末尾必须带/：https://mirrors.aliyun.com/composer/✅，https://mirrors.aliyun.com/composer❌（会拼出错误路径导致 404）
怎么验证镜像真在用？不能只看 config 输出
composer config -g repo.packagist 显示 URL 只说明“配置写进去了”，不代表请求真发到了镜像。必须加 -vvv 看实际网络行为：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 运行
composer show monolog/monolog -vvv 2>&1 | grep "Downloading" - 日志里出现
mirrors.aliyun.com才算真正生效 - 如果仍看到
packagist.org或卡在Loading composer repositories...，说明被项目级repositories覆盖了
项目级配置比全局更可靠，尤其在 CI 和团队协作中
全局配置写在 ~/.composer/config.json，但宝塔、Docker、CI runner 往往以不同用户运行，根本读不到你的配置：
- 进项目根目录，执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 它会自动向
composer.json的repositories字段追加"packagist"条目，不覆盖已有私有源 - 若
composer.json已有"repositories": {}，建议手动编辑，在其中加入"packagist": { "type": "composer", "url": "https://mirrors.aliyun.com/composer/" }，并在顶层加"packagist.org": false
换镜像后还卡在 Downloading？先清缓存再重装
镜像只加速下载，但旧缓存里存着 packagist.org 的元数据，Composer 会优先读缓存并尝试从旧地址校验——结果是卡在 DNS 或 TLS 握手，根本没发请求出去：
- 必须执行
composer clear-cache - 删掉
vendor/和composer.lock - 再跑
composer install --no-cache（禁用缓存强制走新源） - 别试图保留旧
composer.lock——它记录的是旧源的包哈希，和镜像返回的元数据不兼容，必然报hash does not match
最常被忽略的点是：项目根目录下 composer.json 里若有 "repositories" 字段（哪怕只是空对象 {}），就会彻底屏蔽全局镜像配置。验证前务必先检查这个。
