镜像配置失效的主因是键名错误、项目级repositories覆盖全局设置、元数据缓存未刷新；正确写法为composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，且需验证config --list输出并执行--refresh或手动清理缓存目录。
镜像代理失败不是 Composer 坏了，而是配置没生效、缓存没清、或被项目级配置覆盖了——直接改完就跑 composer update，90% 会继续走官方源。
镜像配置写对了但没生效
Composer 的 repo.packagist 配置必须是完整 JSON 对象，不能只写 URL 字符串。常见错误是漏掉 {"type": "composer", "url": "..."} 结构。
- 检查当前全局配置是否合法：
composer config -g repos.packagist.org.url（注意是repos.packagist.org.url，不是repo.packagist） - 若输出为空或报错，说明配置写错了；正确设置应为：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 别用
composer config -g repositories——这个键名已废弃，新版 Composer 会静默忽略
项目级 repositories 字段完全屏蔽全局镜像
只要项目根目录的 composer.json 里有 "repositories" 字段（哪怕值是空数组 [] 或 {}），全局镜像就彻底失效。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 查证方式：
composer config --list | grep repositories，看输出里repositories.packagist.org.url是否为你设的阿里云地址 - 临时禁用项目级配置：
composer config --unset repositories（不加-g） - 永久修复：打开
composer.json，删掉整段"repositories": {...}，注意保留缩进格式避免 JSON 解析失败
composer update 还是卡在旧源？元数据缓存没刷新
Composer 默认缓存 packages.json 元数据 15 分钟，composer clear-cache 对它无效——它只清 ZIP 和 provider 缓存。
- Composer ≥ 2.5：
composer update --refresh强制丢弃所有元数据缓存，从当前镜像重拉 - Composer ≤ 2.4：手动删缓存目录：
rm -rf $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer - 验证是否成功：加
-vvv参数运行composer update -vvv，观察最后几行请求的 URL 是否含mirrors.aliyun.com
换源后仍报超时或 TLS 错误
镜像地址末尾多一个斜杠、CA 证书过期、IPv6 干扰，都会让“换源”变成假动作。
- 确认镜像 URL 正确：
https://mirrors.aliyun.com/composer/（结尾一个斜杠，不能是两个） - 检查 OpenSSL 证书路径：
php -r "print_r(openssl_get_cert_locations());"，看default_cert_file指向的 PEM 文件是否为空或修改时间早于 2022 年 - CI 或内网环境常因 IPv6 导致隐性延迟：加环境变量强制走 IPv4：
COMPOSER_IPV4=1 composer update
最常被跳过的一步是：换源后没清元数据缓存，也没验证 composer config --list 输出是否真变了。镜像配置本身不难，难的是它和项目配置、缓存、网络层三者之间的耦合关系——任何一个环节断开，都会让你以为“换源没用”。
