中文镜像对composer.json解析效率完全无提升，因其仅加速远程元数据（如packages.json）和zip包下载，而composer.json为本地文件，由php直接json_decode读取，不涉及网络请求。
中文镜像对 composer.json 解析效率**完全无提升**——它只影响后续包元数据和 ZIP 包的下载阶段，不参与、也不加速 composer.json 本身的读取与解析。
为什么“解析 composer.json”根本不受镜像影响
composer.json 是本地文件，Composer 启动时直接用 PHP 的 json_decode() 读取并校验，全程不走网络。所谓“卡在 Loading composer repositories”，实际是下一步：去远程拉 packages.json 或 provider-*.json ——这时才轮到镜像起作用。
- 如果你执行
composer install后卡在 “Loading composer repositories”，说明问题出在镜像 URL 配错、DNS 不通、或镜像站尚未同步对应provider-*.json文件，而不是composer.json解析慢 - 若
composer.json本身有语法错误（比如多逗号、单引号），composer validate会立刻报错，且错误信息明确指向行号，和镜像无关 - 大项目中
composer.json超过 2MB？那更可能是误把 lock 文件内容粘进了 json，或者混入了注释——标准 JSON 不支持注释，PHP 会直接json_last_error()报JSON_ERROR_SYNTAX
真正影响依赖解析速度的三个本地因素
“Resolving dependencies” 卡住，99% 和镜像无关，而是本地环境或约束写法导致求解器陷入组合爆炸：
-
"php": "^7.4 || ^8.0 || ^8.1 || ^8.2"这类宽泛约束，会让 Composer 尝试所有满足条件的 PHP 版本对应的包版本组合；改用精确平台声明，如"platform": {"php": "8.2.12"}可大幅收敛搜索空间 - 启用了 Xdebug：运行
php -v看输出是否含xdebug；若有，解析耗时可增加 5–10 倍；临时禁用：php -d xdebug.mode=off $(which composer) install -
composer.lock残留已下线包（如某私有源域名失效），Composer 会逐个尝试超时（默认 10 秒/个）；删掉vendor/和composer.lock后重装，是最干净的起点
镜像只加速哪几个 HTTP 请求环节
镜像生效后，实际替换的是以下三类远程请求的域名和路径，其余全部不变：
-
GET https://repo.packagist.org/packages.json→GET https://mirrors.aliyun.com/composer/packages.json -
GET https://repo.packagist.org/p/provider-laravel~10.0.json→GET https://mirrors.aliyun.com/composer/p/provider-laravel~10.0.json -
GET https://api.github.com/repos/monolog/monolog/zipball/...（dist 下载）→ 实际仍走 GitHub，但packages.json中记录的 dist URL 若被镜像预置为 CDN 地址（如阿里云 OSS），才会替换；多数镜像不改 dist 地址，只加速元数据
注意：provider-*.json 文件缺失或 404，Composer 会 fallback 到全量 packages.json（20+ MB），此时带宽和内存压力陡增——这不是镜像“慢”，而是镜像站同步滞后，你得等它生成该分片文件。
验证镜像是否真在工作，别信感觉
加 -vvv 参数看真实请求地址，比任何配置检查都可靠：
composer install -vvv 2>&1 | grep -E "(GET|Downloading)"
输出里应出现类似：
Downloading https://mirrors.aliyun.com/composer/p/provider-laravel~10.0.json
如果看到的是 repo.packagist.org 或 api.github.com，说明镜像没生效，或被项目级 repositories 数组覆盖。这时候回退查 composer config -g repo.packagist 输出是否为完整 JSON，比反复重试更快。
