composer的--retries参数仅控制dist包下载重试轮数，不延长单次请求超时、不处理dns失败/502/503、旧版本（
Composer默认重试不抗抖动，别信--retries=10能解决问题
Composer的--retries参数只控制dist包下载的**重试轮数**，不是“多试几次就稳了”。它默认用固定延迟（100ms→500ms），且**完全不延长单次请求超时时间**。网络抖动时，CURL error 28（超时）反复出现，重试10次和重试3次结果一样——都是秒败。
更关键的是：--retries在Composer 2.1.x及更早版本中被静默忽略；对git clone来源的包（比如私有仓库没提供dist）完全无效；它也不管DNS失败、502、503这些状态码，遇到就直接退出，不会fallback。
-
--retries只作用于zip/tar包下载，不影响源码克隆 - 单次请求寿命由
COMPOSER_NETWORK_TIMEOUT或http.timeout决定，不是重试次数 - 旧版本不认这个参数，查
composer --version确认是否≥2.2
COMPOSER_NETWORK_TIMEOUT才是真·保命参数
国内弱网环境下卡在Downloading (0%)，90%是因为TLS握手或首字节等待超时。默认http.timeout=60在高延迟链路上根本撑不住。运营商NAT超时常见为120–180秒，你得主动拉长它。
临时生效：运行前加环境变量，比如COMPOSER_NETWORK_TIMEOUT=300 composer install（单位秒）；永久生效：用composer config -g http.timeout 300（注意不是http-timeout，那是旧别名，已弃用）。
- 设太高会拖慢失败感知，建议240–300之间权衡
- IPv6不稳定时加
CURL_IPRESOLVE=4强制走IPv4，避开某些ISP的路由问题 - 如果仍卡住，大概率是镜像源本身响应慢或不可达，不是Composer的问题
镜像源配置≠自动故障转移，别指望它兜底
很多人以为在repositories里写多个源，Composer就会像负载均衡一样自动切流。错。它只是按顺序查元数据——只有第一个源对某包返回明确404，才会去下一个源找；遇到timeout、502、DNS失败，直接报错退出，**绝不会fallback**。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
所以配置镜像源后还在连packagist.org，不是Composer抽风，是你没关掉默认源。正确做法是显式禁用官方源："repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/", "canonical": true}, {"packagist.org": false}]。
-
canonical: true告诉Composer这是主源，其他源仅作补充 - 私有包必须确保镜像源也同步了它的dist包，否则仍会fallback到git clone
- 想验证镜像是否生效？加
-v参数看下载URL，别只信日志里的“Loading from cache”
真要扛住抖动，得自己写shell封装指数退避
Composer没内置指数退避，但你可以用shell硬控：每次失败清缓存、等更久、再试。这比依赖它自身逻辑可靠得多。
示例脚本（bash）：
for i in {1..3}; do
rm -rf vendor/ composer.lock
composer install --no-interaction --prefer-dist && break
sleep $((i * 10))
done
--prefer-dist强制走zip包，跳过易被拦截的git clone；rm -rf vendor/ composer.lock必不可少——残留损坏文件会导致下一次校验失败（比如filemtime(): stat failed）。
- 别用
composer install || sleep 5 && composer install这种写法，不清缓存等于白等 - sleep间隔用$((i * 10))实现指数增长（10s→20s→30s），比固定延迟更适应抖动周期
- CI/CD里建议把这段逻辑封装成可复用的脚本，而不是散落在各个job里
真正难的不是调参，而是理解Composer的重试边界在哪——它只管HTTP层，不管网络层；只管元数据，不管传输稳定性；只管单次请求，不管链路抖动。所有“自适应”都得靠外部机制补足。
