答案是composer diagnose -v输出带[default]标记的镜像才是实际生效项，因配置优先级由运行时动态解析决定而非静态配置；其 Repositories 列表中带[default]者即最高优先级生效源，而config --list仅显示显式设置值，不反映项目级覆盖、环境变量或命令行参数等真实影响因素。

composer config --list 显示的是全局配置，不是实际生效的镜像优先级

很多人执行 composer config --list 后看到 repositories.packagist.org 的值，就以为那是当前生效的镜像地址——其实不是。这个配置只反映「显式设置」的值，而 Composer 实际请求时会按一套优先级规则动态合并：项目级 composer.json、用户级 auth.json 和 config.json、环境变量、甚至命令行参数都可能覆盖它。

真正决定「哪个镜像被用上」的，是 Composer 运行时解析出的最终仓库列表，而不是某一处静态配置。

用 composer diagnose -v 查看运行时解析出的仓库链

composer diagnose -v 是最接近真相的命令。它会在诊断末尾输出类似这样的信息：

Repositories:
 * packagist.org (https://packagist.org) [disabled]
 * packagist.phpcomposer.com (https://packagist.phpcomposer.com) [enabled]
 * packagist.laravel-china.com (https://packagist.laravel-china.com) [enabled, default]

注意三点：

Discussion Composer

围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par

下载

• 带 [default] 标记的才是最终 fallback 的主镜像（即「最高优先级生效项」）
• [disabled] 表示该源被显式禁用，哪怕配置里写了也不会参与请求
• 多个 [enabled] 源存在时，Composer 会按顺序尝试，但只有 [default] 那个承担 packagist.org 的语义角色

为什么 composer config repo.packagist.org 不等于实际镜像

执行 composer config repo.packagist.org 只读取你手动写进配置的值，但以下情况会让它失效：

• 项目根目录 composer.json 中定义了 "repositories": [{"type": "composer", "url": "..."}]，且包含 "packagist.org": false
• 设置了环境变量 COMPOSER_REPO_PACKAGIST，它的值会直接覆盖配置
• 使用了 --repository-url 参数运行 install/update，该次请求完全绕过所有配置
• 某些国内镜像工具（如 composer-proxy）通过修改 http_proxy 或劫持 DNS 生效，根本不改 Composer 配置

验证镜像是否真在起作用的最快方式

别只信配置，要看网络行为：

• 加 -vvv 参数运行任意命令，比如 composer show -vvv monolog/monolog，观察日志里实际 GET 的 URL 域名
• 用 strace -e trace=connect php composer.phar show -n（Linux/macOS）抓底层 socket 连接目标
• 临时删掉所有镜像配置，再运行 composer config -g repo.packagist.org 看是否还残留旧值——很多问题其实是全局配置没清理干净

镜像优先级不是配置树的简单叠加，而是运行时根据上下文动态裁剪的结果；[default] 标记比任何 config 输出都更接近真实行为。