镜像源是静态json文件的http服务，非数据库，无需b-tree索引；性能瓶颈在于packages.json过大、provider同步不全、url末尾缺/、配置三要素（键名repo.packagist、type值composer、url含/）缺一不可。
镜像源根本不是数据库，别折腾B-Tree索引
Composer镜像源不运行任何数据库，也不用B-Tree索引——它就是一堆静态JSON文件（packages.json、provider-2024-07.json、dist/xxx.zip）的HTTP托管服务。所谓“大数据量下变慢”，99%和索引无关，而是以下真实瓶颈：
-
packages.json过大（几十MB）：这是全量快照，不是索引；Composer 2.2+已默认启用分片provider机制，但若镜像未同步或客户端太旧，仍会fallback下载巨无霸 - 请求
provider-2026-06.json却只同步到2026-05：阿里云镜像按月切分，缺失即降级重试，造成隐性延迟 - URL少末尾
/：拼成https://mirrors.aliyun.com/composer/packages.json→ 404 → 静默fallback到官方源，看起来像“镜像没生效”
配置镜像源三要素缺一不可
执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/时，以下三点必须同时满足，否则静默失效：
- 键名必须是
repo.packagist（不是repos.packagist，多一个s就忽略） - 中间
composer是type字段值，小写、不可省略 - URL末尾必须有
/，否则404后直接退到packagist.org
验证是否生效：运行composer config -g repo.packagist，输出必须是完整JSON，形如{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null或纯字符串，说明没写进去。
parallel-downloads设10是多数场景甜点值
这个参数只对composer install起作用，本质是并发HTTP下载数。Composer 2.2+默认是5（≈单线程），设为10可压满千兆宽带，且极少触发临时文件竞争：
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 设15在高配环境可行，但Docker或低内存CI容易报
file_put_contents(/tmp/): failed to open stream - 设20+几乎必然失败
- 验证是否启用：加
-vvv运行composer install，日志中出现Downloading ... (10 concurrent)才算真正生效
注意：parallel-downloads严重依赖镜像支持HTTP/2；如果镜像本身没生效，它连并发机会都没有。
项目级配置会无条件覆盖全局镜像
即使你全局配了阿里云镜像，只要项目composer.json里有"repositories"字段，就会硬编码优先级覆盖——这是Composer底层逻辑，无法绕过：
- 常见陷阱：团队模板自带
"repositories": [{"type": "composer", "url": "https://packagist.org"}]，一拉代码镜像就失效 - 验证是否被覆盖：运行
composer config repo.packagist（不带-g），输出为空或报错，说明项目级接管了 - 临时强制指定镜像：
composer update --repository-url=https://mirrors.tencent.com/composer/
换源后必须立刻composer clear-cache——旧缓存里的元数据仍指向packagist.org，不清缓存，新镜像根本不会被用上。这点最容易被跳过，导致“明明换了源还卡在Downloading”。
