运行 composer config -g --list | grep "repo\.packagist" 确认值为所设镜像URL，再执行 composer show -v laravel/framework | head -20 查看日志中GET请求是否指向该镜像域名。
怎么确认 composer config -g repo.packagist 设置的镜像已生效
改完镜像后不验证，很可能还在走官方源——尤其当你用的是国内网络环境但下载依然慢、超时或报 Could not fetch https://packagist.org/packages.json 时，大概率是配置没生效或被覆盖。
验证的核心逻辑是：看 Composer 实际请求的 URL 是不是你设的镜像地址，而不是看配置命令有没有报错。
- 运行
composer config -g repo.packagist，输出应为类似{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}——这只是查「本地全局配置」，不代表运行时一定用它 - 真正起作用的是运行时加载的完整配置，执行
composer config -g --list，搜repo.packagist这一行，确认值是你设的镜像 URL - 更直接的办法：加
-v参数触发详细日志，比如composer show -v laravel/framework | head -20，观察日志里出现的GET请求地址是否指向你的镜像域名（如mirrors.aliyun.com）
为什么 composer config -g 设置了还是走 packagist.org
常见原因是项目级配置覆盖了全局配置。Composer 加载配置顺序是：当前项目 composer.json 中的 repositories → 当前项目 composer.lock（如果存在且含源信息）→ 全局配置。
- 检查项目根目录下是否有
composer.json，里面是否定义了"repositories"字段，尤其是包含"packagist.org"或"type": "composer"且"url"指向官方源的条目 - 运行
composer config repos.packagist（不带-g），看是否输出非空——有输出就说明项目级配置优先级更高，全局设置被忽略 - 如果项目确实需要自定义源（比如私有包），又想保留镜像加速，可以把镜像配置显式写进项目
composer.json的repositories里，并把 packagist 设为false，再加一条 type=composer 的镜像源
composer diagnose 能不能验证镜像生效
不能直接验证，但能排除部分干扰项。composer diagnose 主要检查网络连通性、权限、CA 证书等基础问题，它会尝试访问 packagist.org 的 API，而不是你配的镜像。
- 如果
diagnose报curl error 7或Connection refused，说明网络根本连不上官方源——这时镜像配置才有意义，但诊断结果本身不反映镜像是否被使用 - 它不会打印实际请求的域名，也不会读取你设的镜像 URL 去测试连通性
- 真正有效的验证动作仍是：用
-v观察真实 HTTP 请求路径，或临时把镜像 URL 改成一个明显错误的地址（如https://invalid-mirror.test），再运行composer update -v，看报错里是不是请求了那个错误地址
Windows / macOS / Linux 下配置位置差异会影响验证吗
不影响验证逻辑，但影响你该去哪查配置。不同系统下 composer config -g 操作的是同一份「全局配置文件」，只是存储路径不同：
- Linux/macOS：
~/.config/composer/config.json（较新版本）或~/.composer/config.json（旧版） - Windows：
%APPDATA%Composerconfig.json - 你可以直接打开这个文件，搜索
"repo":{"packagist"看内容是否符合预期；修改后记得删掉composer.lock（如果存在）再试，否则 Composer 可能复用锁文件里记录的老源地址
最易被忽略的一点：改完镜像后，别只跑 composer install 就以为成了——它可能完全不联网（全靠 composer.lock）。必须触发元数据刷新操作，比如 composer update --dry-run 或 composer show -v xxx，才能看到真实请求行为。
