为什么配置了Composer中文镜像后更新还是需要很久（排障分析）-composer-PHP中文网

composer update卡在resolving dependencies与镜像无关，该阶段纯本地cpu运算，瓶颈在于宽松版本约束、require-dev冲突、php版本错配等；镜像仅加速元数据和zip下载。

为什么配置了composer中文镜像后更新还是需要很久（排障分析）

composer update卡在Resolving dependencies，和镜像无关

这是最常被误判的环节。镜像只影响元数据拉取（packages.json）和 ZIP 包下载，而 Resolving dependencies 阶段完全在本地 CPU 上运行，不发任何网络请求。现象包括：终端长时间不动、htop 显示单核 100%、-vvv 日志停在该阶段、换任意镜像耗时几乎不变。

真正瓶颈通常来自：

版本约束太宽，比如 "^1.0 || ^2.0" 或 "*"，让求解器穷举大量组合
require-dev 引入了高版本工具链（如 PHPUnit 10+），与主依赖冲突
config.platform.php 声明的 PHP 版本低于实际环境，或反过来太宽松
项目中存在大量 path 类型仓库或私有源，增加图遍历复杂度

验证方式：composer why-not vendor/package:version 如果响应极快，但 update 卡住，基本可锁定为约束问题。

镜像配置写对了但没生效，90%出在这三处

配置命令不报错 ≠ 生效。Composer 对键名、type、URL 格式有硬性要求，错一个就静默 fallback 到官方源。

键名必须是 repos.packagist（注意是 repos 复数，不是 repo 单数）
必须显式传入 composer 作为 type 值，漏掉则直接忽略配置
URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（会拼成 /composerpackages.json 导致 404）

验证命令：composer config -g repos.packagist，输出必须是完整 JSON 或纯 URL 字符串；如果为空、null、或仍是 https://packagist.org，说明根本没写进去。

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

元数据缓存未刷新，新版本压根看不见

Composer 默认复用本地 packages.json 元数据缓存（15 分钟内不过期），哪怕镜像站上已同步 monolog/monolog v3.6.0，你本地仍按旧列表计算。

composer clear-cache 不解决这个问题——它清的是 ZIP 和 provider 缓存，packages.json 仍被复用
Composer ≥ 2.5：必须用 composer update --refresh，它只丢弃 packages.json 和 provider-*.json，不碰 ZIP、不重装包
Composer ≤ 2.4：手动删缓存子目录，路径为 $(composer config --global cache-dir)/repo/https---mirrors-aliyun-com-composer

执行前务必确认镜像已生效：composer config -g repos.packagist 输出是你配的 URL；执行后立刻跑 composer update vendor/package，新版本才能被识别。

dist 包仍从 GitHub 下载，镜像没起全链路作用

国内镜像只代理元数据（packages.json），不托管 ZIP 包。如果你看到日志里出现 Downloading https://codeload.github.com/... 或 api.github.com，说明 composer.lock 里记录的 dist.url 还是原始地址。