命令不生效是因为三个硬性条件未同时满足：键名必须为单数repo.packagist、type值必须显式写composer、url必须https且末尾带/；任一缺失即静默回退官方源，验证需输出完整json对象{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。
直接换镜像源，单元测试环境搭建慢的问题基本就解决了——不是你机器差，是默认连 packagist.org 时 DNS 解析、TLS 握手、首字节延迟全卡住，composer create-project phpunit/phpunit 或 composer require --dev phpunit/phpunit 卡在 Downloading 就是典型表现。
composer config -g repo.packagist 命令为什么总不生效
90% 的失败不是网络问题，而是命令写错三个硬性点：
-
repo.packagist（不能是repos.packagist、repositories.packagist或packagist.org） - 中间必须带
composer这个 type 值（漏掉就静默 fallback 到官方源） - URL 必须以
https://开头，且末尾带/（https://mirrors.aliyun.com/composer/✅，少斜杠会拼接出错导致 404）
验证是否写入成功，只看这一条命令输出：composer config -g repo.packagist。返回空、null、Key not found 或仍是 https://packagist.org，说明没生效，立刻重敲。
宝塔或 CI 环境里全局配置为啥对单元测试没用
因为 composer config -g 写的是当前用户的配置（比如 root），而宝塔的「PHP 管理器」、计划任务、GitHub Actions 的 runner、GitLab CI 的 job 默认都以其他用户身份运行（常见如 www、runner），根本读不到你的全局配置。
解决方法很直接：
- 查实际执行用户：
whoami或看日志 UID - 用该用户身份重配：
sudo -u www composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ - CI 脚本里别依赖全局配置，改用临时参数更可靠：
composer require --dev phpunit/phpunit -vvv --repository-url=https://mirrors.aliyun.com/composer/
-vvv 不是可选项，它能打印真实请求 URL，一眼确认是否走镜像——这是排查“为什么还是慢”的第一手证据。
项目级配置怎么避免破坏 PHPUnit 的依赖解析
进项目根目录后执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（不加 -g）。这条命令会自动向 composer.json 的 repositories 字段追加 packagist 条目，而不是覆盖整个数组。
关键点：
- 如果项目已有私有仓库（比如 GitLab 私有包），它不会被删掉，只会追加到数组末尾
- 千万别手动写
"packagist": false，否则phpunit所依赖的基础扩展（如ext-json、php版本约束）校验会失败 - 改完必须删掉
vendor/和composer.lock，再跑composer install（不是update），否则 lock 文件仍指向旧源
镜像只加速下载，不解决 Resolving dependencies 阶段卡顿——如果 PHPUnit 安装过程卡在这里，优先检查 COMPOSER_MEMORY_LIMIT=-1、关掉 xdebug.mode=off、确认 platform.php 和实际 PHP 版本一致。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
