项目级配置会彻底屏蔽全局镜像，只要项目目录下composer.json含有repositories字段，无论内容如何，composer均跳过全局配置；其优先级为项目>全局>默认。
项目级配置会彻底屏蔽全局镜像
只要项目目录下 composer.json 里有 repositories 字段，无论内容是 {}、[] 还是 {"packagist.org": false}，Composer 就完全不读取全局的 repo.packagist 配置——不是优先级低，是压根跳过。这跟“覆盖”无关，是硬性规则：项目 > 全局 > 默认。
常见误判场景：
- CI 脚本用
sudo composer config -g，结果写进/root/.composer/config.json，但构建进程以www-data用户运行，根本看不到 - 宝塔面板后台执行命令默认是
www用户，你在终端用自己账号配的全局镜像对它无效 - 项目
composer.json里已有"repositories": []，此时composer config -g配得再对也白搭
全局配置只对当前用户生效，且极易静默失败
composer config -g repo.packagist 看似简单，但必须同时满足四个硬条件才真正落盘：
- 命令必须带
-g（或--global） - 键名必须是
repo.packagist（写成repos.packagist或packagist.org都无效） - 中间的
composer是type值，不是注释或别名，必须显式写出 - URL 必须是 HTTPS 且末尾带
/，例如https://mirrors.aliyun.com/composer/✅，少斜杠会导致请求/composerpackages.json404
验证是否真写进去了？运行 composer config -g repo.packagist，输出必须是完整 JSON 对象，如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。返回空、null、Key not found 或只有一行 URL，说明没成功，立刻重试。
项目级配置才是协作和部署的唯一可靠方式
进项目根目录后运行 composer config repo.packagist composer https://mirrors.aliyun.com/composer/（去掉 -g），它会把镜像写进 composer.json 的 repositories 对象中，key 固定为 "packagist"。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
注意两个关键约束：
- 如果
composer.json里"repositories"是数组（[]），命令会直接报错；必须先手动改成对象（{}）再执行 - 改完必须删掉
vendor/和composer.lock，再跑composer install，否则锁文件仍指向旧源，镜像形同虚设
这种方式能随代码提交到 Git，所有协作者和 CI 环境行为一致，不需要各自配一遍用户级配置。
换源后卡在 Loading composer repositories？不是镜像没配对，是缓存和锁文件在捣鬼
镜像只加速元数据（packages.json、p2/xxx.json）下载，但 Composer 会优先读本地缓存和 composer.lock 中记录的旧地址。哪怕你刚配好镜像，它也可能还在往 packagist.org 发请求。
必须做的三件事：
- 运行
composer clear-cache清掉本地元数据缓存 - 删掉项目下的
vendor/和composer.lock - 执行
composer install -vvv，观察日志里是否出现mirrors.aliyun.com或mirro（Composer 2.x 日志常截断）
最易被忽略的是：镜像不代理 zip/tar 包的实际下载地址，那些由 composer.lock 或包自身定义的 dist URL 不受镜像控制——所以清锁文件这步绕不开。
