Composer本身不支持自动检测镜像节点，必须靠外部脚本+DNS调度+CDN缓存三者协同；配置需用repo.packagist.org键名、URL末尾带斜杠，且须通过composer config -g验证、curl测延迟、composer install -v查实际请求URL三步确认生效。
Composer 本身不支持自动检测镜像节点，所谓“自动”必须靠外部脚本+DNS调度+CDN缓存三者配合；上线前校验不能只看配置是否写对，得验证实际请求走的是哪个 URL、响应是否来自本地边缘节点。
composer config -g repo.packagist.org 配了但没生效？
这是最常见误判点：配置命令写错键名、漏斜杠、权限不足，都会导致静默失败。
-
repo.packagist是旧键名（v1 时代），v2.2+ 只认repo.packagist.org，写错不会报错，但配置不生效 - 镜像 URL 末尾必须带斜杠，例如
https://mirrors.cloud.tencent.com/composer/，少一个/在部分版本中会 fallback 到官方源 - 若提示
Could not write to /root/.composer/config.json，说明没权限，加sudo或改用用户级配置（composer config -g --auth不适用，这里只是普通配置） - 验证命令必须是
composer config -g repo.packagist.org，不是composer config -g repositories—— 后者输出的是完整仓库数组，易混淆
怎么确认请求真走的是就近镜像？
不能只信 dig 返回了不同 IP，得看 Composer 实际发出去的 HTTP 请求地址和延迟。
- 执行
composer require monolog/monolog -v，在 verbose 输出里找类似Reading composer.json of monolog/monolog (3.0.0)这一行的上一行，那里就是正在访问的镜像 URL - 在不同地区服务器（如北京、广州、新加坡）分别运行
curl -o /dev/null -s -w '%{time_total}\n' https://mirrors.cloud.tencent.com/composer/packages.json，对比延迟是否明显差异；若都 >800ms，说明没走边缘节点 - 用
strace -e trace=connect,sendto php /usr/bin/composer require monolog/monolog -v 2>&1 | grep 'connect('可看到实际连接的 IP，再反查归属地
CI/CD 上线前必须跑的校验脚本
把“配了”和“真用了”拆成两个可断言的步骤，避免部署后才发现卡在下载包上。
- 第一步校验配置：运行
composer config -g repo.packagist.org | grep -q 'mirrors\.' || exit 1，确保返回的是国内镜像域名 - 第二步校验连通性：用
timeout 5 curl -I -s -o /dev/null -w '%{http_code}' https://mirrors.cloud.tencent.com/composer/health，期望返回200 - 第三步校验真实请求路径：临时创建最小项目，
echo '{"name":"test/test"}' > composer.json && composer install -v 2>&1 | grep -o 'https://[^ ]*packages.json' | head -1，检查输出是否匹配预期镜像域名 - 注意：所有校验必须在与线上环境一致的 PHP 版本、扩展（尤其是
openssl和curl）下运行，否则可能本地通、线上挂
最容易被忽略的是 health 接口返回 200 并不代表 packages.json 路径被缓存——如果 CDN 没开启边缘缓存，每次请求仍会回源，延迟陡增。上线前务必确认 /packages.json 和 /p2/ 路径的 Cache-Control 响应头中 max-age ≥ 60 秒。
