composer高并发下载卡住主因是镜像qps限流，需同时配置多镜像源（含"canonical": false）、降低全局并发数至2并清缓存，单换镜像无效。
Composer高并发下载卡住，本质不是网络慢，是镜像QPS被限
Composer install卡在Downloading阶段，90%以上情况不是带宽不足或机器性能差，而是默认并发数（5–10）触发了国内镜像源的QPS硬限制。阿里云、腾讯云、清华等镜像普遍对单IP每分钟请求设上限（如60次），超限后返回429 Too Many Requests或静默丢包。日志里反复出现curl: (28) Operation timed out或Connection refused就是典型信号。
关键点在于：Composer依赖解析是串行的，但下载阶段才真正并行——它不会自动降级，只管发请求。一旦某个镜像响应慢或失败，所有后续请求都得排队等它超时（默认300秒），形成“一个包拖垮全链路”的局面。
必须同时配多镜像 + 降并发 + 清缓存，三者缺一不可
单换一个镜像源（比如只切阿里云）在CI/CD场景下极易卡住，因为批量构建节点会集中打向同一地址，瞬间触发限流。正确做法是启用Composer原生多镜像负载均衡：
- 在项目
composer.json的repositories下添加至少3个国内镜像，并确保每个都带"canonical": false——缺了这个，Composer只认第一个，后面形同虚设 - 全局设低并发：运行
composer config -g repos.packagist.org.concurrent-downloads 2（注意不是http-max-concurrent-downloads，那是旧配置项） - 换镜像后立刻执行
composer clear-cache，否则旧元数据仍走packagist.org，等于白配
验证是否生效：composer config -g | grep concurrent应输出"concurrent-downloads": 2；composer config -g repo.packagist应显示完整URL（注意结尾必须有/，否则拼接路径出错导致404）。
多镜像源之间不存在数据竞争，但顺序决定最终选用哪个
Composer并行下载仅限同一镜像源内多个包的异步HTTP请求，不支持跨repositories并发查询。它严格按repositories数组顺序逐个尝试，首个返回有效元数据的源即被采用，后续完全跳过。因此不存在“多镜像源间数据竞争”——这不是竞态问题，而是配置优先级问题。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
常见误判源于看到composer update -vvv输出中多个GET /p/xxx.json请求几乎同时发出，就以为是多源并发；实际这些请求都发向同一个镜像地址（比如阿里云），只是Composer在该源内部做了连接复用与管道化（HTTP/2）。
验证方式：composer show -a vendor/package输出中source行明确显示最终选用的URL——不是“哪个快选哪个”，而是“哪个先匹配上选哪个”。若你配置了阿里云、腾讯云、官方源三者，但show -a显示的是https://repo.packagist.org，说明前两者根本没返回该包的元数据（可能因镜像同步延迟、包名大小写不一致、或私有仓库未显式声明"packagist": false）。
死锁真正在SAT求解器，和镜像配置无关
当composer install或composer update卡住且CPU持续100%，这不是网络或镜像问题，而是SAT求解器在尝试满足所有require约束时陷入无限回溯。典型信号是终端无报错、无超时、不退出，top中php进程持续高占用。
这种死锁与镜像源完全无关，哪怕你把repositories全删光、只留本地vendor/缓存，只要约束图存在循环（如a → b → a版本范围重叠），求解器照样卡死。
快速确认：composer show -t --no-dev --ignore-platform-reqs | head -50，人工扫描是否出现同一包在不同路径下反复嵌套（如package-a出现在两处子树，且彼此require对方）。别用composer why-not查这个——它只在求解失败后报错时有效；死锁是求解器“还没失败，只是永远算不完”。
