composer diagnose显示的“Repo packagist.org:”行才是实际生效源，它反映Composer解析依赖时真正连接的目标地址；若显示https://packagist.org而非镜像地址，说明配置未生效，需排查JSON格式错误、项目级repositories覆盖或URL缺末尾斜杠等问题。
composer diagnose 显示的 Repo 地址才是实际生效源
运行 composer diagnose 后，重点看这一行输出：Repo packagist.org: https://mirrors.aliyun.com/composer/。它反映的是 Composer 当前解析依赖时**真正连接的目标地址**，不是你“以为”配置的地址。如果这里还是 https://packagist.org，说明镜像没被识别，或被项目级 repositories 覆盖了。
为什么 config -g 输出正确但 diagnose 还是官方源
常见原因有三个，必须逐个排除：
-
composer config -g repo.packagist输出必须是完整 JSON，形如{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}；如果只返回字符串（如"https://..."）或空、null，说明配置根本没写进去 - 项目根目录的
composer.json里存在repositories字段，且其中定义了packagist.org或未显式禁用，默认会覆盖全局设置 - URL 少了末尾
/，比如写成https://mirrors.aliyun.com/composer→ 实际请求会拼成/composerpackages.json，404 后静默 fallback 到官方源
diagnose 报 “Could not fetch” 镜像地址怎么办
这表示网络层已尝试访问你配置的镜像，但失败了。不是配置无效，而是连不通。排查点包括：
- 公司代理或防火墙拦截了该域名，可临时换手机热点测试
- 镜像服务临时不可用（如清华源旧地址
https://packagist.phpcomposer.com已下线） - 本地 DNS 解析异常，试试
ping mirrors.aliyun.com或curl -I https://mirrors.aliyun.com/composer/ - Windows 用户在 Git Bash 中运行
diagnose可能路径识别异常，换 PowerShell 或 CMD 再试一次
还原镜像后必须清缓存再 diagnose
即使你改了配置，Composer 仍可能从旧缓存读取元数据，导致 diagnose 显示错误的 Repo 地址。务必按顺序执行：
composer clear-cache-
composer diagnose—— 此时 “Repo packagist.org” 行才可信 - 如仍不匹配，再补一步：
composer update -vvv 2>&1 | grep "GET "，确认实际 HTTP 请求 URL 是镜像域名
镜像配置本身不复杂，但 Composer 对键名、type、斜杠、JSON 格式极其敏感，错一个字符就静默失效——验证时不能只信命令是否“跑完”，得盯住网络请求那一刻的真实行为。
