最稳的 composer 镜像配置是执行 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/，并强制 ipv4（composer_ipv4=1）与清除缓存（composer clear-cache）；四要素缺一不可：-g、单数 repo.packagist、composer 类型值、末尾带 / 的 https 地址。
最稳的配置不是换多个镜像，而是用一条命令配准阿里云 HTTPS 镜像 + 强制 IPv4 + 清缓存，三者缺一不可。 其他操作如改 hosts、堆 repositories、调 parallel-downloads，多数只掩盖问题，不解决根本阻塞点。
为什么 composer config -g repo.packagist 总是静默失效
这条命令必须严格满足四个要素，漏一个就写进错字段、不报错、不生效：
-
-g：必须加，否则只作用于当前项目目录 -
repo.packagist：键名是单数，repos.packagist（多了一个 s）会写进无效字段，composer config -g repo.packagist查出来为空 -
composer：type 值必须显式写出，不能省略；composer config -g repo.packagist https://mirrors.aliyun.com/composer/缺 type，Composer 2.0+ 直接 fallback 回 packagist.org -
https://mirrors.aliyun.com/composer/：协议必须是 HTTPS，末尾斜杠/不可少；少斜杠会导致请求路径拼成/composerpackages.json，返回 404 且不提示
验证是否真写入：运行 composer config -g repo.packagist，输出应为完整 JSON 对象，例如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。空、null 或报错都说明失败。
WSL2 下镜像“配了但没用”，大概率是 DNS 缓存或项目级覆盖
即使 config -g 输出正确，执行 composer install 仍卡在 Loading composer repositories，常见原因有两个：
-
DNS 缓存未刷新：PHP 的 cURL 复用系统 DNS 缓存，
mirrors.aliyun.com可能仍被解析到海外 IP。不用改系统 DNS，临时加环境变量即可：COMPOSER_NO_INTERACTION=1 composer config -g repo.packagist composer https://mirrors.aliyun.com/composer/ -
项目级
repositories覆盖全局：只要项目根目录composer.json里出现"repositories"字段（哪怕只有一行空数组[]），全局镜像立刻失效。删掉该字段或设为null才能恢复。
验证是否真走镜像：加 -vvv 运行 composer update，grep mirrors.aliyun.com；或跑 composer diagnose，看 Repo packagist.org: 后面显示的地址是不是你设的镜像 URL。
卡在 “Loading composer repositories” 30 秒不动，不是镜像慢，是超时太短
Composer 默认单源等待 30 秒才切下一个——它不判断连接失败，只等满时间。WSL2 下常因 IPv6 fallback、TLS 握手卡顿、DNS 解析慢拖满这 30 秒，导致误判为“镜像不可用”。
- 临时缓解：
composer config -g http.timeout 600（单位秒），把元数据请求超时拉到 10 分钟 - 更治本：
COMPOSER_IPV4=1环境变量强制走 IPv4，绕过 IPv6 探测延迟（尤其在校园网、某些云主机） - 别信“多加几个镜像源就能快”：
repositories数组里放多个源，只有前一个返回 404（包确实不存在）才触发下一个；超时、502、证书错误都不会 fallback，只会死等
执行前务必先 composer clear-cache，否则旧缓存可能让 Composer 继续尝试已失效的地址。
WSL2 下 vendor 写入慢，和镜像无关，是文件系统层瓶颈
如果 composer install 卡在 Installing dependencies 或 Generating autoload files 阶段，不是网络问题，而是 I/O 瓶颈：
- 项目放在
/mnt/c/路径下？这是最大雷区。WSL2 通过 9P 协议挂载 Windows 文件系统，小文件读写性能极差，vendor 解压和 autoload 扫描会慢 5–10 倍 - 必须把项目移到 WSL2 本地路径，如
~/projects/myapp；运行df -h .，确认Filesystem列是ext4或zfs，不是9p - Windows Defender 会高频扫描
ext4.vhdx虚拟磁盘文件，导致解压卡顿甚至超时；需在 Windows 安全中心添加排除项：C:\Users\{user}\AppData\Local\Packages\{distro-name}\LocalState\ext4.vhdx
所有镜像优化的前提，是项目已在 WSL2 本地文件系统。否则其他调整收效甚微——网络再快，也救不了 9P 协议下的 vendor 写入。
php免费学习视频：立即使用
踏上前端学习之旅，开启通往精通之路！从前端基础到项目实战，循序渐进，一步一个脚印，迈向巅峰！
