Composer镜像挂了不会自动切源，这是设计使然而非故障；因其repositories仅作静态元数据合并，下载时只从首个提供完整版本信息的源拉取，超时或5xx错误直接报错，不尝试备用源；真容灾需外部脚本完成探测可用性、动态切换源、清缓存三步原子操作。
composer 镜像服务挂了不会自动切源，这不是故障，是设计如此——它根本没 fallback 机制。真要应对临时性故障，得靠外部控制流主动干预，不是改配置就能躺赢。
为什么 repositories 数组不能当备用源用
你在 composer.json 里写一堆 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，只是让 Composer 按顺序请求每个源的 packages.json 合并元数据，**下载阶段只认第一个能提供该包完整版本信息的源**。一旦这个源返回超时、502 或 DNS 失败，composer install 直接报错退出，连试都不试下一个。
- 常见现象：
Failed to download https://mirrors.aliyun.com/composer/packages.json卡住不动，后续无任何降级提示 - 只有当第一个源对某个包明确返回 HTTP 404（且响应体是 JSON）时，才会查第二个源是否声明了它
- 私有源排在前面？那公共包也可能被“屏蔽”，因为元数据合并后，Composer 认为它只该从私有源找
怎么用脚本实现探测 + 切换 + 清缓存三步原子操作
容灾不是配个 URL 就完事，必须三步一起跑，缺一不可：探测可用性 → 动态写入生效源 → 清缓存避免旧元数据干扰。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 探测镜像根路径是否可访问：
curl -I -s -o /dev/null -w "%{http_code}" https://mirrors.aliyun.com/composer/packages.json，返回200才认为可写入 - 切换项目级配置（比全局更可靠，不被
composer.json覆盖）：composer config repositories.packagist composer https://mirrors.tencent.com/composer/ - 必须执行
composer clear-cache，否则本地缓存的packages.json还指向已失效源 - CI 中建议加重试逻辑，比如循环尝试两个镜像，任一成功即 break：
for mirror in "https://mirrors.aliyun.com/composer/" "https://packagist.laravel-china.org"; do composer config -g repo.packagist.org "$mirror" && break || sleep 2; done
为什么开了签名验证才敢切镜像
直接执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ 会跳过 signature 校验——镜像站不生成也不透传官方 signature 字段，一旦缓存被污染，就可能拉下篡改包。
- 正确做法是启用签名验证：
composer config -g security.signature true - 再设置可信 HTTPS 镜像（仅代理元数据）：
composer config -g repos.packagist.type composer+composer config -g repos.packagist.url https://mirrors.aliyun.com/composer/ - 验证是否生效：
composer diagnose输出中需同时出现secure-http: OK和signature verification: OK - HTTP 镜像会被拒绝，URL 必须以
https://开头、结尾带/，否则composer 2.5+报Invalid repository type
composer.lock 是宕机时唯一可靠的保命线
只要 composer.lock 存在且完整，composer install 就完全离线运行——它只读取 ~/.composer/cache/files 中已缓存的 ZIP 包并校验哈希，不发起任何网络请求。
-
composer.lock必须提交进 Git，禁止出现在.gitignore中 - CI 中应复用
~/.composer/cache目录（如 GitHub Actions 的actions/cache），避免每次重拉 -
composer update必须联网，宕机期间应避免执行；极端情况可强制离线：composer install --no-plugins --no-scripts，但前提是缓存中已有全部包的 dist 文件 - 最容易被忽略的是：镜像配置 ≠ 容灾配置。很多人配了阿里云镜像就以为高枕无忧，却没开 signature 验证、没固化
composer.lock、也没在 CI 中复用缓存——结果镜像一延迟，构建照样失败
