问题在于镜像仅修改元数据源而未更新dist包下载地址，需删除vendor和composer.lock后执行composer install --no-cache；配置镜像时键名、type值、url结尾斜杠缺一不可。
composer install 还在下载 codeload.github.com 是什么问题
这说明镜像只改了元数据源，没更新 ZIP 包的实际下载地址。Composer 的元数据（包列表、版本约束）走镜像，但 dist 包（ZIP 文件）默认仍从 GitHub 原地址拉取——codeload.github.com 就是典型症状。
- 现象：日志里出现
Downloading https://codeload.github.com/...，耗时超 10 秒甚至超时 - 根本原因：
composer.lock里记录的dist.url字段仍是原始 GitHub 地址，换源后没重建 lock 文件 - 必须操作：删掉
vendor/和composer.lock，再跑composer install --no-cache - 别指望
--repository参数能绕过——它只影响元数据拉取，对已存在的composer.lock完全无效
为什么 composer config -g repo.packagist 配了还是不生效
这条命令静默失败的概率极高，不报错也不提示，但配置根本没写进去。关键点就三个，缺一即 fallback 到 https://packagist.org：
- 键名必须是
repo.packagist（单数），写成repos.packagist或repositories.packagist全部被忽略 - 中间必须带
composer这个 type 值：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅，少斜杠会拼成/composerpackages.json导致 404 - 验证方式只有一种：
composer config -g repo.packagist输出必须是完整 URL 或 JSON 对象，空、null、或仍含packagist.org都说明没配对
哪些包根本不受国内镜像加速
镜像只代理 Packagist 上托管的公开包，以下几类完全不走镜像链路：
- GitHub 直链包：
"type": "package"+"dist": {"url": "https://github.com/..."}，这类包直接走原始 URL - 私有 Git 仓库：
"type": "vcs"，比如公司内网 GitLab，需单独配置 SSH 或 token - 本地 path 包：
"type": "path"，完全离线，和网络无关 - 已下线或废弃包：如旧版
phpunit/phpunit，镜像不缓存，每次请求都超时重试
Resolving dependencies 卡住和镜像无关
这个阶段不发任何网络请求，纯本地 CPU+内存计算。哪怕你用的是光速镜像，也救不了它：
-
"minimum-stability": "dev"会让求解器拉取所有 dev 分支元数据，爆炸式增长搜索空间 -
"php": ">=7.4"比"php": "^8.1"多查几百个历史 PHP 版本兼容性 -
"monolog/monolog": "*"或"^1.0 || ^2.0"触发多目标回溯，尤其与其他依赖冲突时 - 没提交
composer.lock到 Git，每次install都强制重算整个依赖图 - Xdebug 启用中会让 SAT 求解慢 5–10 倍；内存不足（默认 128M）也会卡死，临时加
COMPOSER_MEMORY_LIMIT=-1
