composer卡在resolving dependencies的根源是ipv6解析超时而非网速或镜像问题；需设composer_ipv4=1跳过aaaa记录，配正确带斜杠镜像url，并确保环境变量生效。
Composer卡在Resolving dependencies，其实是IPv6在拖慢
不是镜像源慢，也不是你网速差，而是Composer默认先尝试解析AAAA记录、连接IPv6地址，超时（通常1–3秒）后才fallback到IPv4。上百个包叠加，就是几分钟无响应。
验证方法很简单：curl -v https://mirrors.aliyun.com/composer/packages.json，如果看到* Trying 240e::xxx这类输出，说明IPv6正在捣乱；而ping mirrors.aliyun.com返回的应是类似118.31.67.205的IPv4地址才对。
-
COMPOSER_IPV4=1是Composer 2.2+原生支持的开关，直接跳过所有AAAA记录解析，从源头避免fallback延迟 - Docker构建中，在
RUN指令前加ENV COMPOSER_IPV4=1 - GitHub Actions里用
env: { COMPOSER_IPV4: 1 } - 别信
composer config --global http.timeout 600——这只是拉长等待时间，不解决根本问题
镜像URL配置必须带末尾斜杠，且字段名不能拼错
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/这行命令四个要素缺一不可：
-
-g：全局配置，否则只作用于当前项目 -
repo.packagist：单数，写成repos.packagist就存进无效字段 -
composer：type值，不是注释，不能省略 -
https://mirrors.aliyun.com/composer/：末尾/不能少，少了会拼出/composerpackages.json导致404静默失败
Windows和Docker里改完环境变量要重启进程
Windows用户改完COMPOSER_IPV4=1要重启终端，否则PHP进程读不到新环境变量；Docker里用sudo composer config -g写进了root用户配置，但构建用的是www-data，照样不生效。
更稳妥的做法是在Dockerfile里显式声明：
开箱即用的技能链路由引擎。13 条预定义链覆盖搜索、开发、审查、MLOps、法律、创意等场景，三层路由架构（触发词→SAD反馈→DAG编排），recall@10=96.97%。配置驱动（chains.yaml），零代码扩展。pip install skill-weave-chains 一键安装。
ENV COMPOSER_IPV4=1 RUN composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
而不是依赖构建时继承的用户级配置。
Composer不参与BGP路径选择，别指望它“自动走最优线路”
Composer本身不感知BGP双线网络，也不做任何路由决策。它只做三件事：DNS解析域名、建TCP连接、发HTTP请求。所谓“最优路径”，由你的操作系统、内核路由表和上游ISP的BGP路由器决定，Composer拿到的是一个“已经确定好怎么走”的IP地址。
海外节点连国内镜像慢，常见原因是：
- DNS返回了仅限国内访问的CDN IP（比如
dig mirrors.aliyun.com +short返回非公网可达地址） - TLS握手失败：阿里云镜像可能用了国密SM2证书或OCSP Stapling配置不兼容海外根证书库，
curl -vI能确认是否报SSL certificate problem
真正可控的动作只有三个：设COMPOSER_IPV4=1、配好带斜杠的镜像URL、必要时指定可信DNS（如export COMPOSER_DNS=8.8.8.8,223.5.5.5）。其他试图让Composer“智能选路”的操作，基本都是绕远路。
