packagist.org在国内基本不可用，是刚性不可达而非单纯慢；必须配置国内镜像源（如阿里云），且键名repo.packagist、type值composer、url末尾带/三条件缺一不可，否则静默回退官方源。
packagist.org 在国内基本不可用，不是“慢”，而是连接失败、超时、403 或卡死在 Loading composer repositories —— 配镜像不是提速技巧，是能用的前提。
为什么直连 packagist.org 必然失败
Composer 每次运行 install、update 或 require，第一步就是全量拉取元数据（packages.json 及其分片），这个过程必须走 HTTPS，且依赖 DNS 解析、TLS 握手、CDN 路由。国内实测：packagist.org 平均首字节时间（TTFB）超 8 秒，失败率约 37%，中间还常被拦截或重置连接。
现象不是报错，而是命令行停在 Loading composer repositories with package information 超 90 秒，毫无进度提示——你等的不是下载，是根本没开始。
- DNS 解析慢：
packagist.org域名在国内无有效解析缓存，常超时 - TLS 握手不稳定：部分运营商或防火墙会干扰 SNI 或证书链验证
- 无 CDN 节点：官方源未部署国内边缘节点，请求全部绕行海外
composer config -g repo.packagist 为什么经常不生效
这条命令看似简单，但三个硬性条件缺一不可，任一出错 Composer 就静默 fallback 回 packagist.org，还不报错：
- 键名必须是
repo.packagist（单数，不能写成repos.packagist或repositories.packagist.org） - 命令中必须显式带上
composer这个type值（漏掉就当无效参数处理） - URL 必须以
/结尾（https://mirrors.aliyun.com/composer/✅，少斜杠会拼成/composerpackages.json导致 404）
验证是否成功，只看这一行输出：composer config -g repo.packagist。如果返回空、null、{"type":"composer","url":"https://packagist.org"}，说明配置失败。
全局配置 vs 项目级配置：哪个更可靠
全局配置写在 ~/.composer/config.json（Linux/macOS）或 %USERPROFILE%\AppData\Roaming\Composer\config.json（Windows），但它只对当前用户生效。CI 流水线、宝塔后台、Docker 构建往往以 www 或 runner 用户运行，根本读不到你的全局配置。
项目级配置更稳，直接改 composer.json：
- 执行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 它会自动向
"repositories"数组追加 packagist 条目，不覆盖已有私有源 - 配置随 Git 提交，新人克隆即用，CI 构建无需额外 setup
- 务必补上
"packagist.org": false，否则 Composer 仍会 fallback 到官方源
换镜像后还是卡？先确认请求发到了哪
镜像只解决元数据和 ZIP 包的分发，不加速依赖解析（Resolving dependencies）。如果仍卡住，立刻做三件事：
- 加
-vvv看日志：composer install -vvv | grep -i "downloading\|mirrors\|packagist"，确认请求域名是不是你配的镜像地址 - 手动测试镜像可用性：
curl -I https://mirrors.aliyun.com/composer/packages.json，看是否返回200 OK - 检查是否有废弃插件拖累：老项目若用了
fxp/composer-asset-plugin，它不走 Composer 镜像，会额外请求 Bower/NPM 源，而这些源没国内镜像
真正卡住的时候，别反复调 composer config，先验证网络层通不通——比瞎试快得多。
