应执行composer config -g repos.packagist查看全局镜像url，再用curl -i测试返回200/304才有效；阿里云已迁至/php-composer/路径，腾讯云需user-agent头，华为云需企业认证，且必须clear-cache才能生效。
Composer镜像不是“配一次就一劳永逸”的东西，过期、失效或响应变慢的镜像会直接拖垮 composer install 速度，甚至导致依赖解析失败。国内主流镜像（如阿里云、腾讯云、华为云）通常每 3–6 个月会调整服务策略或下线旧域名，必须定期验证和更新。
如何检查当前镜像是否仍有效
执行 composer config -g repos.packagist 查看全局配置的镜像 URL；再用 curl -I https://mirrors.aliyun.com/composer/packages.json（替换为你实际配置的地址）测试 HTTP 状态码——返回 200 或 304 才算可用。若出现 403、404 或超时，说明该镜像已停用或限制访问。
- 阿里云镜像在 2025 年底已将旧路径
https://mirrors.aliyun.com/composer/迁移至https://mirrors.aliyun.com/php-composer/ - 腾讯云镜像自 2026 年 3 月起要求携带
User-Agent头，否则返回403，需配合composer config -g http-basic.mirrors.tencent.com user pass（如有认证）或改用无认证镜像 - 华为云镜像已关闭匿名访问，仅限企业账号绑定后使用
镜像配置应避免硬编码在 composer.json 中
把镜像写死在项目级 composer.json 的 repositories 字段里，会导致所有协作者、CI 流水线、Docker 构建都强制走同一源——一旦该镜像出问题，整个团队卡住。更稳妥的做法是只在全局或构建环境配置：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 开发机：用
composer config -g repos.packagist composer https://mirrors.aliyun.com/php-composer/ - Dockerfile：在构建阶段加入
RUN composer config -g repos.packagist composer https://mirrors.aliyun.com/php-composer/，而非 COPY 项目级配置 - CI/CD：通过环境变量
COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/php-composer/注入（部分 CI 支持）
镜像失效时的快速回退方案
别等 composer update 卡住十分钟才发现问题。遇到超时或 Could not fetch packages.json 错误，优先尝试以下三步：
- 临时禁用镜像：
composer config -g repos.packagist→ 记下原值，再执行composer config -g --unset repos.packagist - 换备用镜像：
composer config -g repos.packagist composer https://packagist.phpcomposer.com（PHP Composer 社区维护，轻量但稳定性略低） - 强制走 dist + 跳过 SSL 验证（仅调试）：
composer install --prefer-dist -n --no-ansi -vvv |& grep -A5 "Downloading"观察真实请求地址和失败点
最常被忽略的一点：镜像配置本身不会自动刷新缓存。即使你刚切到新镜像，Composer 仍可能从旧镜像缓存中读取过期的 packages.json。执行 composer clear-cache 后再重试，才是完整闭环。
