composer卡在resolving dependencies本质是sat求解器暴力回溯版本冲突，非网络问题；需先配对镜像源（composer config -g repo.packagist）、清缓存（composer clear-cache）、验证provider同步状态，并配合composer why-not定位约束冲突。
Composer 卡在 Resolving dependencies 不是网络慢，也不是“递归太深”，而是 SAT 求解器在爆炸的版本组合空间里反复回溯失败——镜像源没配对、元数据没同步、缓存还残留着 packagist.org 的旧索引，三者叠加，直接让解析卡死。
镜像源必须配对 repo.packagist，不是改 repositories
很多人往 composer.json 的 repositories 数组里加了阿里云地址，但 composer install 还是卡在 Downloading https://repo.packagist.org/...。这是因为 Composer 3.x+ 把官方包元数据源（packages.json、provider-laravel~10.0.json 等）硬编码为单点路由，repositories 列表只影响私有源，不接管 Packagist 元数据请求。
真正生效的只有这一条命令：
composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/
注意四个关键点：
-
-g缺失 → 只在当前项目生效，换目录就失效 -
repo.packagist写成repos.packagist（多一个 s）→ 静默忽略 - URL 末尾缺
/→ 请求变成https://mirrors.aliyun.com/composerpackages.json，404 - 漏掉
composer类型参数 → 被当成普通 HTTP 源，不走元数据协议
清缓存不是可选项，是必做动作
换镜像后仍卡在 Loading repositories 或报 Could not fetch packages.json，90% 是因为缓存没清。Composer 会优先读本地元数据缓存，哪怕你已经配好镜像，它仍用旧缓存里的 packagist.org 地址去请求 provider 文件。
必须执行：
composer clear-cache
验证是否生效：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
-
composer config -g repo.packagist输出应为完整 JSON 或字符串 URL -
composer show packagist/support中的source.url字段必须含镜像域名（如mirrors.aliyun.com） -
composer install -vvv日志末尾出现Reading packages.json from cache at /https---mirrors-aliyun-com-composer/
provider 分片同步滞后，是卡住的隐形原因
Packagist 的元数据不是单个大文件，而是按时间/命名空间切片的：provider-laravel~10.0.json、provider-symfony~6.0.json 等。镜像同步有延迟，常滞后几小时。一旦你要装的包对应 provider 文件还没同步，Composer 就会卡在 Downloading https://mirrors.aliyun.com/composer/p/provider-laravel~10.0.json 并反复重试。
快速定位方法：
- 用
curl -I https://mirrors.aliyun.com/composer/p2/laravel/framework/10.0.0.json测试 - 再比对官方源：
curl -I https://repo.packagist.org/p2/laravel/framework/10.0.0.json - 若官方返回 200、镜像返回 404 → 同步未完成，临时切中科大源：
composer config -g repo.packagist composer https://mirrors.ustc.edu.cn/composer/
并发下载调到 15 才压得满带宽
元数据快了只是第一步；后续 tarball 下载也得跟上。Composer 2.2+ 默认并发数为 5，对国内多节点镜像过于保守。
实测将并发提到 15，整体安装耗时下降 40%～60%：
composer config -g parallel-downloads 15
但别设到 20+：
- DNS 解析可能超时，报
Failed to decode response - 触发阿里云/腾讯云镜像限流，反而出错
- 这个参数不影响元数据检索，只加速下载阶段
真正的瓶颈永远在元数据同步逻辑和约束收敛程度上——镜像配错、缓存不清、provider 滞后、约束太松，四者任一没解决，调再高的并发也没用。
