Composer镜像配置失效的根本原因是命令漏掉三个硬性条件：键名必须为单数repo.packagist、type值必须显式写composer、URL必须HTTPS且末尾带/；任一缺失即静默回退官方源，验证需输出完整JSON对象。
composer config -g repo.packagist 命令为什么总不生效
根本不是网络问题，而是命令漏了三个硬性条件，Composer 2.x 遇到就静默 fallback 到 https://packagist.org，连警告都没有。
-
repo.packagist必须是单数形式——写成repos.packagist、packagist.org或大小写混用（如Repo.Packagist）都无效 - 中间的
composer是必需的type值，不是注释，不能省略，也不能当别名用 -
URL必须是 HTTPS 且末尾带/，例如https://mirrors.aliyun.com/composer/✅，少斜杠会拼出/composerpackages.json导致 404 ❌
验证是否真写进去了：运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，形如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null、报 Key not found，或只有一行原始 URL 字符串，说明配置失败，立刻重试。
项目级配置比全局更可靠，尤其在 CI/宝塔/Docker 环境
全局配置写在 ~/.composer/config.json，但它只对当前 shell 用户生效。CI 流水线用 runner 用户、宝塔后台用 www 用户、Docker 容器常以非登录用户运行——它们根本读不到你的全局配置。
- 先进入含
composer.json的项目根目录，再执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意不加-g） - 该命令会自动识别
composer.json中已有的repositories结构：如果是对象（{}），就安全写入"packagist"键；如果是数组（[]），会报错，需先手动改成对象再重试 - 千万别手写
"packagist.org": false——这会让 Composer 屏蔽基础包校验，导致php、ext-json等平台依赖无法验证
换源后依然卡在 “Loading composer repositories” 怎么办
镜像只加速元数据下载，但 Composer 会优先读取本地缓存和 composer.lock 中记录的旧地址。哪怕你刚配好镜像，它也可能还在往 packagist.org 发请求。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 先清缓存：
composer clear-cache - 删掉整个
vendor/目录 - 删掉
composer.lock - 再执行
composer install（不是update）——install会重新解析composer.json+ 当前镜像配置，生成新lock文件，并从镜像源下载所有包
跳过这步，大概率看到 “Loading composer repositories” 卡住，或者报 file could not be downloaded 错误。
怎么确认镜像真的在起作用
不能靠命令有没有报错，得看实际网络请求发往哪里。
- 检查
composer.json是否出现标准结构："repositories": {"packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}} - 加
-vvv跑一次安装：composer install -vvv 2>&1 | grep -i 'mirrors\.aliyun\|tuna\.tsinghua'，确认日志中出现镜像域名 - 如果日志里还出现
https://packagist.org/packages.json或https://packagist.org/p/x，说明镜像根本没走通，回头检查前面三个副标题里的硬性条件
最容易被忽略的是：改完配置后没删 composer.lock 和 vendor，就直接 composer update——这会导致旧 hash 与镜像元数据不匹配，结果还是回退到官方源拉包。
