答案是配置错误或PHP环境受限导致镜像失效。常见原因：键名写错（如repos.packagist多s）、缺type值composer、URL末尾无斜杠；PHP禁用proc_open/putenv也会使config命令失败；项目级repositories字段还可能覆盖全局配置。
配了镜像还是慢、卡在 Loading composer repositories、Connection refused 报错——根本不是网络问题，而是配置写错了或 PHP 环境没过审。
为什么 composer config -g repo.packagist 总是不生效？
命令看似跑完了，但 composer config -g repo.packagist 输出为空或报错，说明根本没写进去。常见原因有三个：
-
repo.packagist键名不能多写一个s（repos.packagist是无效键，不报错但完全忽略） - 命令里必须带
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❌（少斜杠会拼出 404 路径）
验证是否真生效：运行 composer config -g repo.packagist，输出必须是类似 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 的完整 JSON 对象。
PHP 环境禁用了关键函数，config -g 直接失败
报错如 proc_open(): disabled、putenv(): disabled 或 command not found，不是 Composer 问题，是 PHP CLI 层面被锁死了。
立即学习“PHP免费学习笔记（深入）”；
- 检查
php.ini中的disable_functions行，确认proc_open和putenv没出现在里面（连空格都不能多） - 改完后必须重启终端（CLI 模式）或重载 PHP-FPM/Apache/Nginx
- 快速验证：
php -r "echo function_exists('proc_open') ? 'ok' : 'fail';"，输出ok才算通过
别跳过这步——很多“镜像配好了却没用”的案例，卡在这儿。
换源后 composer install 报 hash 不匹配或包找不到
镜像只改下载路径，不兼容旧 composer.lock 文件里的哈希和元数据来源。强行复用会触发 hash does not match 或 package is not installed。
- 删掉项目根目录下的
vendor/和composer.lock - 再执行
composer install（不是update），让 Composer 从新镜像重新拉取元数据并生成 lock - 如果项目已有自定义
repositories字段，确保里面没有残留packagist.org，否则优先级高于全局镜像
临时验证是否真走镜像？开另一个终端，运行 tcpdump -i any host mirrors.aliyun.com（Linux/macOS）或用 Wireshark（Windows），看到请求发过去才算数。
项目级配置比全局更稳，尤其在 CI/CD 和团队协作中
全局配置依赖用户环境，CI 容器里往往没配，或不同成员本地配置不一致，导致 install 结果不可复现。
- 进项目根目录，运行
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉-g） - 这条命令会自动向
composer.json的repositories数组追加 packagist 条目，不破坏已有私有源 - CI 流水线中建议用环境变量：
COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/ composer install
真正容易被忽略的是：镜像解决不了依赖解析阶段的卡顿（比如大量 ext-* 校验失败），那得查 PHP 扩展是否真加载了——php -r "var_dump(extension_loaded('curl'));" 输出 bool(true) 才算过关。
