90%的composer安装慢源于镜像未生效或依赖求解卡顿；必须严格执行composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/、composer clear-cache，并验证输出为完整json，同时注意项目级配置、用户权限及resolving dependencies阶段与网络无关。
Composer安装慢，90%不是网络差，而是镜像根本没生效，或者卡在本地依赖求解——换源只加速下载，不解决“Resolving dependencies”卡顿。
composer config -g repo.packagist 命令写对了吗
这条命令极易静默失败，且不报错。必须同时满足三个硬条件：
-
repo.packagist不能写成repos.packagist（多一个s就彻底忽略） - 中间必须带
composer这个 type 参数：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/✅；漏掉composer就 fallback 到默认源 ❌ - URL 必须是 HTTPS + 末尾带斜杠：
https://mirrors.aliyun.com/composer/✅；https://mirrors.aliyun.com/composer❌（少斜杠会拼出/composerpackages.json导致 404）
验证是否成功：运行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象，空、null 或仍是 https://packagist.org 都说明没写进去。
换源后为什么 composer install 还是慢
最常被跳过的一步：composer clear-cache 没执行。缓存里还存着旧的 packages.json 和元数据，Composer 会优先读缓存，哪怕配置已改，它仍试图从旧地址拉校验信息，结果卡在 DNS 解析或 TLS 握手。
其他关键干扰项：
- 项目级
composer.json中存在repositories字段，会直接覆盖全局配置；可用composer config --list和composer config --list --global对比确认实际生效的是哪个 - 宝塔、CI 或计划任务以
www用户运行，但composer config -g写的是root配置（路径为/root/.composer/config.json），www完全读不到；应切到对应用户下执行：sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - 用了过时插件如
hirak/prestissimo，它在 Composer 2.2+ 中不仅无效，还会干扰原生parallel-downloads
Resolving dependencies 卡住跟镜像无关
这个阶段完全不走网络，是 Composer 在本地穷举满足所有约束的版本组合。尤其当你写了 "*"、"^1.0 || ^2.0" 或 "minimum-stability": "dev" 时，求解器会指数级爆炸。
常见诱因包括：
-
php版本约束太宽，比如"php": "^7.4 || ^8.0" - 大量未锁定版本的
dev包（如"monolog/monolog": "dev-main"） -
require-dev里塞了太多工具，尤其是含复杂依赖的测试/构建工具
这类问题换任何镜像都无效，必须收紧约束、删掉冗余 dev 包、或临时加 --prefer-stable 降低求解压力。
临时验证镜像是否生效的最可靠方式
别依赖 composer config -g 输出，直接用 -vvv 看真实请求地址：
composer update -vvv --repository=https://mirrors.tuna.tsinghua.edu.cn/composer/- 输出中搜索
GET请求，确认 URL 是镜像域名而非packagist.org
这种临时参数优先级最高，绕过所有配置文件和缓存，能快速定位是配置问题还是镜像本身延迟/同步滞后。注意：部分镜像（如腾讯云）对 p2/ 路径支持不全，-vvv 日志里若出现 404 或回退到官方源，就说明该镜像当前不兼容你的 Composer 版本。
