应检查三处：执行composer config -g repo.packagist确认输出是否为{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；确保URL末尾有/且未被项目级repositories覆盖；运行composer clear-cache后，用composer install -vvv | grep "mirrors-aliyun"验证日志。
composer install -vvv 日志里看不到 mirrors.aliyun.com？配置根本没生效
很多人以为执行了 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 就万事大吉，结果 composer install -vvv 日志里还是满屏 https://packagist.org 或 https://repo.packagist.org。这不是网络卡，是镜像压根没被读取。
真正起效的标志只有一条：日志中出现类似这样的路径：
Reading packages.json from cache at /home/user/.composer/cache/repo/https---mirrors-aliyun-com-composer/packages.json
验证前必须确认三件事：
-
composer config -g repo.packagist输出必须是完整 JSON（旧版）或纯 URL（新版），形如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或仍是https://packagist.org都说明写入失败 - 拼写必须是
repo.packagist，不是repos.packagist（多一个s会静默忽略） - URL 末尾的
/不可省略——漏掉会导致 Composer 拼出https://mirrors.aliyun.com/composer/packages.json，404 后自动 fallback 到官方源，且不报错
进度条卡在 “Downloading” 却没请求发出？缓存没清干净
换源后仍卡在 Downloading xxx.zip 且无实际网络请求，大概率是旧缓存里的 packages.json 和 provider 元数据还在作祟。Composer 会优先读本地缓存，再校验远程地址——哪怕你已切镜像，它仍反复尝试从 https://packagist.org 拉索引，卡在 DNS 解析或 TLS 握手阶段。
必须执行：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
composer clear-cache（注意不是composer cache-clear，后者已废弃） - 看到两行输出才算成功：
Clearing cache (cache-dir):和Clearing cache (cache-vcs): - 临时绕过缓存验证：加
--no-cache参数跑一次composer install -vvv，看日志里请求域名是否变成镜像地址
项目级 repositories 覆盖全局配置，导致进度提示“假快真慢”
项目根目录 composer.json 中的 repositories 字段优先级高于全局配置。如果你在项目里写了：
"repositories": [{"type": "composer", "url": "https://packagist.org"}]
那全局镜像就完全失效，composer install 看似有进度条，实则仍在走海外源，下载速度和超时风险一点没变。
检查方式：
- 运行
composer config --list和composer config --list --global对比，确认repo.packagist实际生效的是哪个 - 进项目根目录，用
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不带-g）追加配置，它会自动合并进repositories，不覆盖已有私有源 - CI/CD 或 Docker 构建中，全局配置常因用户身份问题（如宝塔用
www用户）读不到，项目级配置更可靠
parallel-downloads 或 http-max-concurrent-downloads 设太高，进度条“动得快”但实际失败
设高并发参数能让进度条刷得飞快，但容易掩盖底层错误。比如 parallel-downloads 20 在低配 CI 环境下可能触发 file_put_contents(): failed to open stream，表现为进度条突然卡死或报错退出。
安全做法：
- Composer 2.2+ 用
http-max-concurrent-downloads（parallel-downloads已弃用） - 推荐值设为
8或10：composer config -g http-max-concurrent-downloads 8 - 该参数只对
composer install下载 ZIP 包有效，不影响依赖解析；若镜像未生效，它连并发机会都没有 - 并发效果依赖镜像站支持 HTTP/2，阿里云、清华、腾讯云都支持；私有源不支持的话，设再高也白搭
composer install -vvv 的最后一行日志里，不在命令是否成功执行，也不在进度条跳得多快。 
