Composer install卡在Loading repository说明镜像未生效，90%因配置错误：键名必须为repo.packagist（单数）、type值必填composer、URL须含末尾/；验证需同时满足config输出正确JSON及install -vvv日志显示镜像路径。
composer install 卡在 Loading repository 说明镜像根本没生效
进度条停在 Loading composer repositories 阶段，90% 是因为配置写错了，不是网络问题。Composer 这一步只读全局配置，不走网络——但它会按配置去尝试连接那个 URL，如果 URL 错（比如少斜杠、拼错键名），就会卡在 DNS 或 TLS 握手，看起来像“卡住”。
-
repo.packagist必须是单数，repos.packagist（多一个 s）或repositories都无效，且不报错 - 命令末尾必须带
composer类型标识：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/✅；漏掉composer就 fallback 到官方源 ❌ - URL 必须以
/结尾：https://mirrors.aliyun.com/composer/✅；https://mirrors.aliyun.com/composer❌（路径拼接后 404） - 验证方式唯一：运行
composer config -g repo.packagist，输出必须是{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}或纯 URL 字符串；空、null、含packagist.org都说明失败
卡在 Resolving dependencies 不是镜像问题，是本地约束太松
这一阶段完全离线，Composer 在本地穷举满足所有版本约束的组合。写 "*"、"^1.0 || ^2.0" 或设 "minimum-stability": "dev" 会让求解器指数级爆炸，尤其在大型项目里，可能卡住几分钟甚至十几分钟。
- 收紧版本约束：把
"*"改成具体范围，例如"^2.5"；避免跨主版本的 OR 表达式 - 删掉
"minimum-stability": "dev"，改用"prefer-stable": true - 检查
composer.lock是否过旧：它记录的是原始 dist URL，换源后执行composer update --lock强制刷新下载地址 - 某些包（如 GitHub 上的 path 类型或私有仓库）会绕过镜像直连，这类依赖无法加速，需单独处理
卡在 Downloading 后无响应，大概率是缓存没清或 vendor 写入失败
换源后仍卡在 Downloading xxx (v1.2.3)，常见原因是旧缓存还在，或者容器/CI 环境下 vendor 目录权限不对、挂载异常。
- 必须执行
composer clear-cache—— 否则 Composer 仍从缓存读旧的packages.json和元数据，尝试向旧地址发起 HTTPS 请求 - Docker 构建时，确保
~/.composer/cache挂载为 volume，否则每次构建都重拉元数据 - 确认
vendor目录可写：CI 中常因用户权限（如 www 用户）导致写入失败，日志可能静默中断 - 临时跳过 autoload 生成和脚本执行：
composer install --no-autoloader --no-scripts --prefer-dist，适合部署阶段
日志里出现 mirrors.aliyun.com 但还是慢，说明项目级配置覆盖了全局
即使 composer config -g repo.packagist 输出正确，只要项目根目录 composer.json 里存在 "repositories" 字段，全局镜像就会被完全忽略——这是 Composer 的硬性优先级规则。
- 运行
composer config --list和composer config --list --global对比，确认实际生效的是哪一层 - 若
composer.json有"repositories": [...]，哪怕内容为空数组，也会屏蔽全局设置 - 临时强制使用阿里云镜像：
composer install --no-plugins --repository=https://mirrors.aliyun.com/composer/ - 最彻底办法：删掉
composer.json中整个"repositories"区块（注意保留缩进），再重试
composer config -g repo.packagist 输出、-vvv 日志里真实请求的域名、以及 composer.json 里有没有悄悄覆盖它的字段。 
