composer没有自动重连机制，其“重试”实为curl底层按策略重试，用户可配置重试次数、超时阈值等参数；需同时满足可恢复错误识别、重试开关开启、延迟足够宽三条件才能生效。
Composer 本身没有“自动重连机制”可定制——它不维护连接池，也不做健康探测或失败转移。所谓“重连”，实际是底层 curl 在 HTTP 请求失败时按策略重试，而 Composer 只负责配置和触发这个过程。你真正能调的，是重试次数、超时阈值、协议解析行为这些参数。
为什么改了镜像 URL 还卡在 Connection timeout？
这不是镜像问题，而是 curl 在首次连接失败后没进入重试路径。常见原因有：
-
http-timeout设得太小（比如60），而镜像响应慢于该值，直接报A connection timeout was encountered，跳过重试逻辑 - 用了
COMPOSER_IPRESOLVE=4但镜像域名只支持 IPv6，CURL_ERROR 7不触发重试 - 代理环境只配了
HTTP_PROXY没配HTTPS_PROXY，curl直连失败后不走代理重试（Composer 默认全走 HTTPS） - 自定义
retries值为0，或用了--no-retry-auth-failure但实际遇到的是429而非认证错误
怎么让重试真正生效？
必须同时满足三个条件：请求被识别为“可恢复错误”、重试开关开启、延迟窗口足够宽。实操建议：
Discussion Composer
下载
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 全局设重试次数：
composer config -g retries 5（默认是3，但对国内镜像波动更友好） - 调高超时：
composer config -g http-timeout 300（给镜像留出缓冲时间，避免误判为不可恢复） - 禁用 IPv4 强制解析：
unset COMPOSER_IPRESOLVE或删掉该环境变量，让curl自动选可用协议 - 确认代理完整：
export HTTPS_PROXY=http://your-proxy:8080（HTTP_PROXY和HTTPS_PROXY都要设）
镜像同步延迟导致重试无效？
重试不会帮你绕过元数据陈旧问题。比如镜像还没同步到新包的 provider-*.json，你反复重试只会重复拉取旧索引。这时重试再多次也没用：
- 先验证镜像实时性：
curl -I https://mirrors.aliyun.com/composer/packages.json | grep -i "last-modified"，对比 Packagist 官方头 - 强制刷新元数据：
composer update --refresh（≥2.5 版本才支持，会丢弃本地缓存并重新下载） - 清空本地缓存：
composer clear-cache（否则--refresh可能仍读缓存） - 检查是否被项目级
repositories覆盖：composer config repositories，确认输出里是你期望的镜像 URL
真正容易被忽略的是：重试只作用于单次 HTTP 请求，它不解决镜像元数据不同步、DNS 解析失败、TLS 握手卡死这类前置问题。如果你看到日志里反复出现 Failed to decode response 或 Invalid package information，那大概率不是重试能救的——得换源、清缓存、或等镜像同步。
