正确配置 composer 镜像的命令是：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/；必须包含 repo.packagist（不可多s或少前缀）、type 值 composer、url 以 / 结尾，否则静默失效。
composer config -g repo.packagist 配置必须带斜杠和 type 值
PHP 单元测试环境（如 PHPUnit + Mockery）依赖安装慢，常因 composer install 卡在 Downloading https://api.github.com/ ——这不是测试框架本身的问题，而是镜像没配对。阿里云镜像只代理元数据，不托管 zip 包，但元数据请求若没走镜像，后续所有包都会 fallback 到直连 GitHub。
真正生效的命令只有一条：composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/。漏掉任意一个要素都会静默失效：
-
repo.packagist不能写成repos.packagist或packagist（多一个 s 或少前缀都不行） - 中间的
composer是type值，不是可选参数，省略后 Composer 2.2+ 会直接忽略该配置 - URL 必须以
/结尾，否则请求路径拼接错误（例如https://mirrors.aliyun.com/composerpackages.json），返回 404 后自动回退到packagist.org
验证是否成功：composer config -g repo.packagist 输出应为 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 或至少是完整 URL 字符串；空、null 或仍显示 https://packagist.org 说明没写进去。
项目级配置比全局更可靠，尤其用于 CI 中的单元测试
本地配好了，CI 流水线里 composer install 还卡住？大概率是运行用户不一致：GitHub Actions 用 runner 用户，GitLab CI 默认用 root，宝塔部署走 www 用户——它们各自读自己的 ~/.composer/config.json，互不影响。
解决办法是把镜像写进项目本身，让 composer.json 成为唯一真相源：
- 进入项目根目录，执行：
composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加-g） - 这条命令会向
composer.json的repositories字段安全追加 packagist 条目，不覆盖已有私有源 - 如果
composer.json已有"repositories": {}（对象形式），它能 merge；如果是"repositories": []（数组），命令会失败，需先手动改为对象 - 务必保留
"packagist.org": true（不是false），否则镜像不可用时整个依赖链断裂
改完立刻删掉 vendor/ 和 composer.lock，再跑 composer install ——旧 lock 文件里的 dist URL 是直连 GitHub 的，不删它，镜像配置等于白配。
单元测试环境卡在 Resolving dependencies？和镜像无关
镜像只加速元数据拉取和 zip 下载，不影响依赖解析阶段。如果你的 PHPUnit 测试套件在 Resolving dependencies 卡住几十秒，重点排查这些真实瓶颈：
- PHP 内存不足：
php -d memory_limit=-1 $(which composer) install临时放开限制（默认 128M 对复杂测试依赖常不够） - Xdebug 开着：
php -d xdebug.mode=off $(which composer) install关掉它，解析速度可提升 5–10 倍 -
platform配置错位：比如"php": "7.4"却在 PHP 8.5.5 环境下跑，Composer 会反复降级查找兼容版本 - 依赖树太深：某些测试工具（如
phpunit/phpunit+doctrine/dbal+symfony/console）组合容易触发高开销解析，可尝试--prefer-dist强制走预编译包
composer install -vvv | grep "Resolving" 能确认卡点是否真在此阶段；若日志里全是 Downloading，才回头查镜像。
临时换源验证镜像是否真起作用
不想动任何配置，又想快速验证某个镜像在当前环境下是否可用？用 --repository 参数：
composer create-project phpunit/phpunit --repository=https://mirrors.aliyun.com/composer/ test-envcomposer update -vvv --repository=https://mirrors.tuna.tsinghua.edu.cn/composer/
注意：--repository-url 是无效参数名，必须写成 --repository=xxx；且该参数只影响当次命令，不写入任何配置文件。
-vvv 是关键——它会打印出实际发起的 HTTP 请求 URL。看到 Loading composer repositories from https://mirrors.aliyun.com/composer/ 就说明镜像已接管元数据请求；如果仍有 https://api.github.com/ 出现，说明 zip 下载环节仍直连 GitHub，得考虑 ghproxy 或清理 composer.lock。
真正麻烦的从来不是配镜像，而是锁文件里埋着旧路径、运行用户搞错、或把元数据加速和 zip 加速混为一谈。每一步都得对着 composer install -vvv 的输出逐行核对，别信“应该生效了”。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
