最准验证方式是执行composer config -g repos.packagist.org.url，输出必须为https://mirrors.aliyun.com/composer/（末尾无斜杠）；若为空或仍为https://packagist.org，说明被项目级repositories字段覆盖。
cURL error 28 不是网速慢，是 DNS 解析卡住、TLS 握手失败，或镜像源本身响应延迟——换对镜像 + 清缓存 + 调 http.timeout 才能真正稳住。
怎么确认镜像源真生效了？
很多人改完配置却没效果，是因为镜像根本没走通。执行以下命令验证：
-
composer config -g repos.packagist.org.url输出必须是https://mirrors.aliyun.com/composer/（末尾不能带斜杠） - 如果输出仍是
https://packagist.org或空，说明配置被项目级composer.json中的repositories字段覆盖了 - 临时绕过项目配置测试：运行
composer install --repository=https://mirrors.aliyun.com/composer/ -v，看是否还卡在Loading composer repositories
为什么换了阿里云镜像还是超时？
常见原因不是镜像不行，而是底层网络环节卡死：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- DNS 解析失败：运行
ping mirrors.aliyun.com，若返回unknown host，说明系统 DNS 异常，需改/etc/resolv.conf（Linux/macOS）或网络适配器 DNS（Windows） - TLS 握手卡住：用
curl -v https://mirrors.aliyun.com/composer/packages.json观察是否停在* TLS handshake—— WSL2 时间不同步、公司中间件拦截、证书链不全都可能导致此现象 - IPv6 干扰：国内多数镜像站 IPv6 支持不完整，CI 环境默认启用 IPv6 就会隐性拖慢甚至失败，加
COMPOSER_IPV4=1强制走 IPv4
http.timeout 和 process-timeout 到底该设谁？
这两个参数作用层完全不同，混用等于白调：
-
http.timeout控制单次 HTTP 请求总耗时（DNS + TCP + TLS + 响应头），适用于cURL error 28和Could not fetch https://...类错误；建议设为600 -
process-timeout控制整个命令生命周期（依赖解析、下载、解压、执行脚本），适用于卡在Generating autoload files后长时间无响应；建议设为1200 -
process-timeout超过7200秒会被 Composer 主动忽略并回退到300秒——这是硬编码限制，设再大也没用
CI/CD 中反复超时怎么固化配置？
容器每次重启都会丢掉全局配置，COMPOSER_HOME 不固化就等于没配：
- 脚本开头必须显式设置：
export COMPOSER_HOME=/tmp/composer，再跑composer config -g ... - 强制走 IPv4：
COMPOSER_IPV4=1 composer install（Windows 下设环境变量COMPOSER_IPV4 = 1，值是字符串1，不是布尔） - 别在 CI 上跑
composer update：它会重新解析依赖树，耗时远高于install；应基于已提交的composer.lock执行 - 禁用并行下载降低压力：
composer config -g concurrent-connections 1，尤其在低配 CI 节点上更稳定
镜像源只加速 dist 包（ZIP/TAR），对 "prefer-source": true、私有 Git 仓库、硬编码的 git@ 地址完全无效——这些情况会 fallback 直连，触发超时。检查 composer.json 是否含这类配置，才是最易被忽略的根因。
