换镜像后仍429是因动态ip共享出口导致限流叠加，须同步配置至少3个带"canonical": false的国内镜像、降并发至2、清缓存、验证url结尾斜杠，并在ci/cd中启用--no-dev/--no-scripts/--no-autoloader。
为什么换镜像后还是429：动态IP导致限流叠加
公司出口用NAT、云服务器弹性IP、CI/CD构建节点轮换——这些场景下，你的请求看似来自不同机器，实则共享同一出口IP池。镜像源（如阿里云、腾讯云）按IP做QPS硬限流，而动态IP让限流计数器无法复位，结果是“刚清缓存，立刻被封”。这不是配置错，是限流策略和网络架构的天然冲突。
- 典型现象：
composer install卡在Downloading，日志反复出现curl: (28) Operation timed out或429 Too Many Requests - 验证方式：执行
curl -I https://mirrors.aliyun.com/composer/packages.json，看响应头是否含X-RateLimit-Remaining: 0 - 关键误区：以为“换一个镜像就行”，但单镜像 + 动态IP = 瞬间打满配额，尤其在CI中批量构建时
必须同时启用多镜像 + "canonical": false
Composer原生支持多镜像负载均衡，但默认只认第一个；缺 "canonical": false 字段，其余镜像全被忽略——这是最常漏掉的配置点。
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
- 在项目根目录
composer.json的repositories下添加至少3个国内镜像，例如： "type": "composer", "url": "https://mirrors.aliyun.com/composer/", "canonical": false"type": "composer", "url": "https://mirrors.tencent.com/composer/", "canonical": false"type": "composer", "url": "https://packagist.phpcomposer.com/", "canonical": false- 注意：每个镜像URL结尾必须带
/，否则路径拼接出错导致404 - 不要删掉默认的
packagist.org配置，Composer会自动 fallback，但需确保它排在最后且不设canonical
concurrent-downloads 必须设为2，不是调大
默认并发5–10，对动态IP环境是灾难——所有请求几乎同时发出，极易触发镜像端秒级QPS阈值。降为2不是妥协，而是匹配镜像实际承载能力。
- 执行全局配置：
composer config -g repos.packagist.org.concurrent-downloads 2 - 旧参数
http-max-concurrent-downloads已废弃，设了也无效 - 验证是否生效：
composer config -g | grep concurrent应输出"concurrent-downloads": 2 - CI/CD中若用容器镜像预装Composer，需确保该配置已写入基础镜像，否则每次构建都重置
CI/CD里必须关掉--no-dev等干扰项
开发时有用的参数，在CI中反而加剧限流压力：生成autoload、执行scripts、加载dev依赖都会额外触发元数据请求，变相增加API调用次数。
-
--no-dev：跳过require-dev包，减少约30%的包解析请求 -
--no-scripts：禁用post-install-cmd等钩子，避免意外调用npm或git命令引发二次请求 -
--no-autoloader：不生成vendor/autoload.php，后续用composer dump-autoload --optimize单独补 - 漏掉任意一项，
composer install -vvv日志里会出现大量串行的Downloading https://...，而非交错并行
--no-dev，可能让构建时间翻倍——这些点不在报错信息里，但决定你能不能真正跑通。
