镜像源仅加速元数据和dist包下载，不影响lock解析、hash校验、脚本执行及path仓库扫描；实际提速取决于项目结构，需配合parallel-downloads、禁用path扫描、启用prefer-dist才能显著提效。
镜像源本身不加速composer install，只加速元数据和dist包下载
很多人以为“换镜像 = install变快”，其实composer install耗时主要分三块：解析composer.lock、校验本地vendor/、下载缺失的dist包（或clone source）。镜像只影响最后一步里的网络请求——而且仅限于两类URL：
-
https://mirrors.xxx.com/composer/packages.json（元数据索引） -
https://mirrors.xxx.com/composer/dists/vendor/name/hash.zip（具体dist包）
它对以下环节完全没提速：
- 读取本地
composer.lock文件（纯I/O） - 验证已安装包的SHA256 hash（CPU密集）
- 执行
post-install-cmd脚本（如autoload dump） - 逐个读取
"type": "path"仓库的composer.json（见下条）
实际提速幅度取决于项目结构，不是固定百分比
如果你的项目只有10个包、全走dist、lock文件干净，换阿里云镜像后composer install可能从8秒降到3秒——提升约60%。但若项目是Monorepo含47个path子包，那90%时间花在Reading composer.json上，换镜像后仍是8秒，毫无改善。
关键判断点：
- 运行
composer install -vvv，看日志里Downloading行是否密集出现（说明镜像起作用） - 如果大量
Reading ./packages/xxx/composer.json穿插其中，说明瓶颈在本地扫描，换镜像无效 - CI日志里出现
file_put_contents(/tmp/): failed to open stream，说明parallel-downloads设太高，不是镜像慢
镜像配置错误会导致“看似生效实则 fallback”
常见静默失效场景：
-
composer config -g repos.packagist（多一个s），Composer直接忽略，仍走packagist.org - URL写成
https://mirrors.aliyun.com/composer（缺末尾/），返回404，Composer自动fallback到官方源拉packages.json（20MB+） - 项目
composer.json里有"repositories": []空数组，全局镜像被屏蔽
验证是否真走镜像：抓包或看Nginx日志，确认请求的是/composer/packages.json而非/packages.json；后者说明已fallback到官方源，此时任何镜像优化都归零。
真正决定install速度的三个开关比镜像更重要
比起纠结用阿里云还是华为云，先确认这三项是否打开：
-
parallel-downloads设为8（composer config -g parallel-downloads 8），Composer 2.2+才有效 - 禁用
path扫描：composer config -g repositories.path.type disabled，避免几十个子包反复读JSON - 删掉项目级
"prefer-source": true，确保走--prefer-dist（国内镜像只缓存dist）
这三个操作做完，多数项目composer install能从15秒压到4秒内；没做之前，换十次镜像也卡在12秒不动。
