需通过 composer diagnose 检查是否显示“Repo.packagist is configured”并结合 -vvv 日志或抓包确认真实请求域名，三者缺一不可。
如何确认 composer config -g repo.packagist 设置的镜像已生效
直接运行 composer config -g repo.packagist 只会输出当前配置值，但不等于实际请求走的是这个地址。真正生效需要同时满足「配置写入正确」+「未被项目级配置覆盖」+「网络请求实际命中镜像域名」。
- 配置值必须是完整 URL，且以
https://开头（如<a href="https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9">https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9</a>），不能漏掉末尾斜杠，否则 Composer 会降级回官方源 - 如果当前目录下有
composer.json或composer.lock，运行composer install时优先读取项目根目录的composer.json中的repositories字段，会完全屏蔽全局镜像 - 某些代理或公司内网环境会劫持 DNS 或强制重定向，即使配置了阿里云镜像，
curl -I <a href="https://www.php.cn/link/307e9c61450651aa146fa8da4ddd4906">https://www.php.cn/link/307e9c61450651aa146fa8da4ddd4906</a>仍可能返回 200，但 Composer 内部请求却被转发到官方源（表现为下载慢、超时、出现Could not fetch <a href="https://www.php.cn/link/307e9c61450651aa146fa8da4ddd4906">https://www.php.cn/link/307e9c61450651aa146fa8da4ddd4906</a>）
用 composer diagnose 快速暴露配置冲突
该命令会检查全局和本地配置一致性，并明确提示镜像是否被覆盖：
composer diagnose
重点关注输出中这两行：
-
Repo.packagist is default (<a href="https://www.php.cn/link/5b4ba6e852444462a8e1223fc42e1af8">https://www.php.cn/link/5b4ba6e852444462a8e1223fc42e1af8</a>)→ 表示没生效，正在用官方源 -
Repo.packagist is configured (<a href="https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9">https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9</a>)→ 表示全局镜像已加载
但注意：diagnose 不验证网络连通性。如果镜像域名能解析但 HTTPS 证书异常（比如中间人代理），它依然显示“configured”，而实际请求会失败。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
抓包验证真实请求地址（最可靠）
Composer 默认使用系统 cURL，可通过临时设置环境变量捕获真实请求：
COMPOSER_HTTP_PROXY=127.0.0.1:8080 composer require monolog/monolog
然后用 mitmproxy 或 Charles 监听 127.0.0.1:8080，观察发起的 GET 请求目标域名。若看到大量 GET /packages.json 请求发往 mirrors.aliyun.com，说明镜像生效；若仍是 packagist.org，说明配置被绕过。
更轻量的方法是加 -vvv 参数看调试日志：
composer clear-cache && composer require monolog/monolog -vvv 2>&1 | grep "Downloading"
输出中会出现类似：
Downloading <a href="https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9p2/monolog/monolog.json">https://www.php.cn/link/1569ae888190eb8c53b218b0d529e1e9p2/monolog/monolog.json</a>
如果这里还是 packagist.org，就说明根本没走镜像。
常见覆盖场景与排查顺序
- 当前目录存在
composer.json，且其中定义了"repositories": [{"type": "composer", "url": "<a href="https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19">https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19</a>"}]→ 删除该段或改为镜像地址 - 运行过
composer config repo.packagist <a href="https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19">https://www.php.cn/link/ec811d0d775adc62776ba80fadd4ed19</a>（无-g）→ 这会写入当前项目配置，优先级高于全局，用composer config --unset repo.packagist清除 - 使用了 Docker 或 CI 环境，
HOME目录不是预期路径 → 检查composer config -g --list输出的 config file 路径是否可读 - 镜像服务本身不可用（如清华源偶尔维护），但 Composer 不报错，只默默回退 → 用
curl -I <a href="https://www.php.cn/link/3c1906bb3a2d55ca4a6bfc8522940f01">https://www.php.cn/link/3c1906bb3a2d55ca4a6bfc8522940f01</a>手动测通
镜像配置看似简单，但 Composer 的配置叠加逻辑、环境变量干扰、以及请求链路中的静默降级，会让“明明设了却没走”成为高频问题。真要确认，别只信 config -g 的输出，得看请求发去了哪。
