composer config -g repo.packagist 输出不等于生效，因项目级 repositories 覆盖、缓存未清或配置字段缺失会导致静默回退官方源；须用 composer require -vvv --dry-run 查日志中实际请求域名验证。
composer config -g repo.packagist 输出不等于生效
很多人执行 composer config -g repo.packagist 看到 URL 就以为镜像配好了，其实这只是“你写进去的内容”，不是 Composer 实际请求时用的源。它可能被项目级 repositories 覆盖、可能因缓存未清而继续走旧地址、也可能因字段缺失根本没加载。
真正生效要靠网络请求验证
最直接的办法是触发一次真实包拉取，并观察实际 HTTP 请求目标：
- 先运行
composer clear-cache—— 不清缓存，90% 的“换源失败”问题都出在这 - 再运行
composer require --dry-run psr/log（或任意小包），加-vvv参数：composer require -vvv --dry-run psr/log - 在输出日志里搜
GET或Downloading，确认 URL 是https://mirrors.aliyun.com/composer/这类镜像地址，而不是https://packagist.org/ - 如果卡在
Loading composer repositories...且日志里出现packagist.org，说明配置没生效或被覆盖
为什么 composer diagnose 不靠谱
composer diagnose 只检查配置格式和基础连通性，完全不显示当前实际使用的仓库 URL，也不校验 repo.packagist 是否被项目级配置屏蔽。它可能输出 “OK”，但你 install 依然慢如蜗牛。
- 想查全局显式设置：用
composer config -g repo.packagist（只看这一项） - 想查项目最终合并结果：用
composer config -l | grep repo，但注意它不标注来源，repositories字段若存在，会直接禁用全局镜像 - 项目根目录若有
composer.json且含"repositories"数组，第一项必须是{"packagist.org": false}，否则全局镜像被无视
Windows 和 sudo 权限导致的“假失效”
配置看似成功，但换终端或换用户就失效，大概率是权限路径错位：
- Windows 下改完必须重启命令行/PowerShell/终端，否则读的是旧环境变量或旧配置缓存
- Linux/macOS 下误用
sudo composer config -g→ 配置写进/root/.composer/config.json，普通用户运行时根本读不到 - 验证路径是否对：运行
composer config -g home，看输出的路径是不是你预期的用户级目录（如/home/xxx/.composer）
真正卡住的地方从来不是命令怎么写，而是你以为配好了，其实 Composer 根本没读那行配置——尤其当项目里有 repositories、缓存没清、或者权限路径不对时，它一声不吭地退回原始源。
