项目级repositories字段存在时全局镜像被完全屏蔽，非优先级低而是直接跳过；必须满足repo.packagist单数、type为composer、url以/结尾且https，验证需输出完整json。
项目级 repositories 字段会完全屏蔽全局镜像配置
只要 composer.json 里存在 repositories 字段（哪怕值是 {}、[] 或 {"packagist.org": false}），Composer 就不会读取全局的 repo.packagist 配置——不是“优先级低”，而是直接跳过。这是一条硬规则：项目 > 全局 > 默认。
常见踩坑点：
- CI 脚本用
sudo composer config -g写进/root/.composer/config.json，但构建进程以www-data用户运行，根本看不到该配置 - 宝塔面板后台执行命令默认是
www用户，你在终端用自己账号配的全局镜像对它无效 - 项目已有
"repositories": []，此时无论composer config -g repo.packagist配得多准，都白搭
全局配置只对当前用户生效，且极易静默失败
composer config -g repo.packagist 看似简单，但必须同时满足四个条件才真正落盘：
- 命令必须带
-g（或--global） - 键名必须是
repo.packagist（写成repos.packagist或packagist.org都无效） - 中间的
composer是type值，不是注释或别名，必须显式写出 - URL 必须是 HTTPS 且末尾带
/，例如https://mirrors.aliyun.com/composer/✅；少斜杠会导致请求/packages.json时 404
验证是否成功？运行 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 --no-cache。旧composer.lock记录的是官方源的包哈希，和镜像元数据不兼容，必然触发hash does not match
全局配置失效时，依赖解析仍可能卡在 Resolving dependencies
换镜像源只加速元数据拉取和包下载，不加速依赖分析（Resolving dependencies）。这个阶段是本地 SAT 求解，完全不发网络请求。所以即使全局镜像没生效，你看到的卡顿也大概率不是网络问题。
真实瓶颈常是：
-
php.ini中memory_limit过低（默认 128M 不够） - 启用了
xdebug -
composer.json里写了过于宽泛的版本约束（如"*"或"^1.0 || ^2.0"）
验证方式：临时设 COMPOSER_MEMORY_LIMIT=-1 再跑，若明显变快，说明就是内存不足。镜像配得再对，也救不了本地求解逻辑本身。
