Composer镜像配置失效主因是键名错（应为repo.packagist）、缺type值composer、URL末尾无/，三者任一出错即静默回退官方源；验证需输出完整JSON或URL字符串，且-vvv日志中请求域名须匹配镜像站。
装不上、卡在 Loading composer repositories 或 Downloading，大概率不是网络差，是默认连的 packagist.org——DNS 解析慢、TLS 握手不稳定、首字节延迟高。换中文镜像能从等两分钟变成等两秒，但配错一个字符就等于没配。
composer config -g repo.packagist 命令为什么总不生效？
它根本没写进去，而且 Composer 一声不吭，照连官方源。原因集中在三处：
-
repo.packagist写成repos.packagist（多一个 s）或packagist.org，键名错，静默忽略 - 漏掉中间的
composer—— 这是type值，不是可选参数；缺了它，Composer 2.x 直接 fallback 到默认源 - URL 少了末尾斜杠：
https://mirrors.aliyun.com/composer❌，必须是https://mirrors.aliyun.com/composer/✅，否则拼出/composerpackages.json导致 404 - 你在终端用 root 配的，但宝塔、Docker 或 CI 脚本是以
www或runner用户运行，读的是各自家目录下的~/.composer/config.json
验证是否真写进去了：运行 composer config -g repo.packagist，输出必须是完整 URL 字符串或 JSON 对象。空、null、或仍显示 https://packagist.org，说明失败。
项目级配置比全局更靠谱，怎么安全加？
进项目根目录（确保有 composer.json），执行这条命令：
立即学习“PHP免费学习笔记（深入）”；
composer config repo.packagist composer https://mirrors.aliyun.com/composer/
它会自动向 composer.json 的 repositories 字段追加 "packagist" 条目，不覆盖已有私有源。好处是：
- 配置随代码提交，新人 clone 即用，行为一致
- CI 构建时容器每次启动都读最新
composer.json，不用额外 setup - 避免全局配置被不同用户、不同项目覆盖的权限和路径问题
- 如果
composer.json原来是"repositories": {}，命令会转为标准数组格式并插入；手动编辑 JSON 容易少逗号、多引号，直接报错
改完后务必跑一次 composer update --lock，让 composer.lock 记录新源地址。
换了镜像还卡在 Downloading？先清缓存再重装
镜像只加速下载环节，但旧缓存里存着 packagist.org 的元数据，Composer 会优先读缓存、尝试从旧地址校验——结果就是卡在 DNS 或 TLS 握手，根本没发请求到镜像。
- 执行
composer clear-cache - 删掉
vendor/和composer.lock - 再跑
composer install --no-cache（禁用缓存，强制走新源） - 别试图保留旧
composer.lock：它记录的是旧源的包哈希，和镜像返回的元数据不兼容，必然报hash does not match
验证是否真走镜像，不能只看 config 输出。实测命令：composer show monolog/monolog -vvv 2>&1 | grep "Downloading"，日志里必须出现 mirrors.aliyun.com 或 mirrors.tuna.tsinghua.edu.cn 等镜像域名。
真正容易被忽略的点：换源解决不了 Resolving dependencies 卡顿——那是本地 CPU 在解依赖树，和镜像无关。PHP 版本错位、xdebug 开着、内存不足、composer.json 太复杂，这些才是慢的根源。
