最稳的移动网络 composer 镜像设置是执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer（末尾无斜杠），并强制 ipv4、调高超时、清缓存、设重试；漏任一要素（-g、单数键名、type值、url格式）均静默失效。
移动网络下 Composer 镜像连接不稳定，核心不是“换源不够多”，而是默认行为在高丢包、DNS 波动、IPv6 fallback、TLS 握手不稳的链路上天然吃亏——必须关掉干扰项、强制确定路径、缩短失败等待。
为什么移动网络下镜像经常卡在 “Loading composer repositories”
这不是镜像站问题，是 Composer 默认策略在弱网下被放大：它先尝试 IPv6 地址（哪怕你没配），DNS 解析超时后才 fallback 到 IPv4；TLS 握手失败不重试，直接等满 30 秒才切下一个源（但你只配了一个）；http-timeout 默认 300 秒，而移动网络单次 TLS 握手抖动就可能耗尽。
- 必须加
COMPOSER_IPV4=1环境变量，绕过 IPv6 探测（尤其在 4G/5G 切换或地铁隧道场景） -
composer config -g http-timeout 600和composer config -g process-timeout 600要一起设，否则process-timeout会提前 kill 进程 - 别信“加了镜像就稳了”——如果
composer config -g repo.packagist输出仍是https://packagist.org或为空，说明配置根本没生效
移动网络下最稳的镜像命令必须带全四要素
执行这条命令才能真正生效：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer（注意末尾无斜杠）。漏掉任意一项都会静默失败：
Workflow Decomposer
下载
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
-g：必须全局，移动设备常多用户切换，项目级配置容易被忽略 -
repo.packagist：键名必须是单数，写成repos.packagist就存进无效字段 -
composer：type 值不能省，不是注释，也不是可选参数 -
https://mirrors.aliyun.com/composer：末尾不能有/，否则请求变成//packages.json导致 404
如何验证镜像真正在移动网络下起作用
别只看 composer config -g 输出，要抓真实请求路径：
- 加
-vvv执行composer install，搜日志里是否出现mirrors.aliyun.com—— 如果只有packagist.org，说明配置被项目composer.json中的repositories覆盖了 - 用手机热点开电脑终端，运行
curl -I https://mirrors.aliyun.com/composer/packages.json，看是否秒回200；若超时，说明本地 DNS 或运营商劫持仍在干扰 - 清缓存必须跟换源同步：
composer clear-cache，否则 Composer 仍用旧的海外元数据索引发起请求
移动网络专属的兜底配置组合
仅换镜像和调超时还不够，移动网络波动大，得加一层容错：
- 重试次数必须显式设：
composer config -g retries 5（Composer 2.2+ 支持），避免单次 TLS 握手失败就中断 - 禁用并行下载：
composer config -g http-max-concurrent-downloads 1，某些运营商对并发连接限速或重置，反而更稳 - 临时跳过 SSL 校验仅用于调试：
composer config -g secure-http false，但上线前务必恢复，生产环境严禁 - 如果用 CI 工具（如 GitHub Actions），所有配置都得用环境变量方式：
COMPOSER_IPV4=1 COMPOSER_HTTP_TIMEOUT=600 composer install，避免配置未加载
移动网络的不确定性在于它不报错，只沉默等待。真正起效的不是“多试几个镜像”，而是让 Composer 的每一步行为都变得可预测、可拦截、可超时控制——尤其是那个默认 30 秒的 IPv6 fallback，它在地铁里能吃掉你一半安装时间。
