根本原因是默认连接境外packagist.org导致DNS解析慢、TLS握手卡、首字节延迟高甚至超时；必须配置带结尾斜杠的国内镜像源（如https://mirrors.aliyun.com/composer/），并确保全局配置不被项目级repositories覆盖，同时通过composer diagnose或-vvv验证生效。
国内开发者用 Composer 装包慢、超时、404，根本原因不是网络差，而是默认走 packagist.org（境外源），且没配对镜像规则。解决它不靠“多试几次”，而在于让 Composer 真正信任并持续使用中文镜像——这需要同时满足三件事：全局配置生效、项目级不覆盖、URL 末尾有斜杠。
为什么 composer config -g repo.packagist 总是不生效
这条命令本身没错，但 Composer 的源优先级是硬编码的：项目级 composer.json 中的 repositories > 全局 config > 默认 packagist.org。只要项目根目录下 composer.json 里写了 "repositories": {} 或任何非空对象，哪怕只有一行空花括号，全局镜像就彻底失效。
- 先执行
composer config --list（在项目目录下），看输出里有没有repositories相关字段 - 如果有，打开
composer.json，删掉整个"repositories"键；或者改成"repositories": [{"packagist": false}]显式禁用默认源，再加镜像 - CI/CD 构建中慎用
sudo composer config -g——它写进的是 root 用户的~/.composer/config.json，而构建进程常以普通用户运行，压根读不到
https://mirrors.aliyun.com/composer 少个 / 就 404
Composer 拼接镜像 URL 是硬编码逻辑：你配的地址 + packages.json。如果配成 https://mirrors.aliyun.com/composer（缺结尾斜杠），请求就会变成 https://mirrors.aliyun.com/composerpackages.json，直接 404。
- 正确写法必须带结尾斜杠：
https://mirrors.aliyun.com/composer/✅ - 其他可用镜像（同样需带
/）：https://mirrors.cloud.tencent.com/composer/、https://mirrors.huaweicloud.com/composer/ - 验证是否真生效：运行
composer diagnose，重点看Repo packagist.org:后面的域名是不是你设的镜像；更直接的是composer install -vvv 2>&1 | grep -i "mirrors\|packagist"，确认实际请求 host 是镜像站
多个镜像怎么配才不白配
Composer 不支持自动 fallback。它按 repositories 数组顺序查，第一个返回非 200 就报错，不会继续往后试。
立即学习“PHP免费学习笔记（深入）”；
- 想用阿里云主镜像 + 官方兜底，不能只写一个 URL，得手动写全数组：
"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}, {"packagist": true}] - 注意顺序：把镜像放前面，
{"packagist": true}放最后，否则一旦镜像临时不可用（比如返回 503），Composer 就直接失败，不会退到官方源 - Docker 构建时，
composer config -g写的配置不会持久化到镜像层，必须在RUN指令里显式执行，或直接把repositories写进composer.json
镜像配好了，升级依赖还是卡在 Resolving dependencies
这时候问题已不在网络，而在依赖约束本身。Composer 2.x 的 SAT 求解器比 v1 更严格，只要当前 composer.json 和锁文件里的约束合起来找不到可行解，它就停住不动，不妥协、不降级、不提示具体谁拦路。
- 别删
composer.lock硬来，先跑composer why-not vendor/package:^new-version，它会输出一条反向拒绝链，从最后一行倒着读才能定位真正卡点 - 常见卡点是某个
require-dev包锁死了旧版子依赖（比如phpunit/phpunit要求sebastian/exporter ^4.0，而你要升的框架要求^5.0） - 升级大版本（如 Laravel 10）时，必须配合
--with-dependencies：例如composer update laravel/framework --with-dependencies，否则只动框架本体，留下一堆不兼容的子依赖在 vendor 里
镜像只是加速通道，不是万能解药。真正决定升级能否平滑的，是 composer.json 里每一行 require 的松紧程度、conflict 字段是否存在、以及你是否愿意花两分钟读完 composer why-not 的输出——那几行文字，往往比重装十次 Composer 都管用。
