Composer install卡在“Loading composer repositories”是因为未正确配置国内镜像源：必须严格使用repo.packagist（单数小写）、显式指定composer类型参数、URL末尾带斜杠，且需通过composer config -g repo.packagist验证输出为完整JSON，否则静默回退至packagist.org。

composer install 卡在 “Loading composer repositories”？不是网络差，是根本没走国内镜像——配错一个字符就等于没配。

为什么 composer config -g repo.packagist 总是静默失效

这条命令不报错、不提示，但实际还在直连 https://packagist.org。90% 的失败源于三个硬性条件漏掉任一：

• repo.packagist 是唯一合法键名（注意：单数、全小写；写成 repos.packagist 或 packagist.org 直接忽略）
• 中间必须显式传入 composer 作为 type 值（漏掉它，Composer 2.x 会 fallback 到官方源）
• URL 必须是 HTTPS 且末尾带斜杠：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（缺斜杠会导致请求路径拼成 /composerpackages.json，404）

验证是否写入成功，只看这一行输出：
composer config -g repo.packagist
正确结果应为完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}；空、null、或仍是 https://packagist.org，说明根本没写进去。

项目级配置比全局更可靠，尤其在宝塔/CI/Docker 中

全局配置写在当前用户的 ~/.composer/config.json，但宝塔默认用 www 用户执行，CI 流水线用 runner，Docker 容器里可能是 www-data——它们都读不到你本地 root 或个人账户下的配置。

Discussion Composer

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

下载

• 进项目根目录（有 composer.json 的地方），运行：
  composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意：不加 -g）
• 该命令会自动向 composer.json 的 repositories 字段追加条目，不会清空已有私有源
• 如果原 composer.json 是 "repositories": {}，命令会转为数组并插入；如果是 "repositories": []，需先手动改成对象结构再运行
• 改完务必执行：
  composer update --lock，让 composer.lock 记录新源地址

临时换源排查问题，--repository-url 是第一选择

不想动全局或项目配置？又想快速验证是否是镜像问题？直接加参数最干净：

• 临时走阿里云镜像：
  composer install --repository-url=https://mirrors.aliyun.com/composer/
• 对比清华源稳定性（IPv6 更稳）：
  composer require monolog/monolog -vvv --repository-url=https://mirrors.tuna.tsinghua.edu.cn/composer/
• 加 -vvv 可确认真实请求 URL 是否含 mirrors.，这是唯一能 100% 确认镜像命中的方式
• CI 脚本中强烈推荐这种方式，避免用户权限、配置覆盖等干扰

换源后仍卡在 Resolving dependencies？和镜像无关

镜像只加速下载环节（Downloading、Fetching package），不解决依赖解析慢的问题。

• 若 composer update 卡在 Resolving dependencies 超过 10 秒，大概率是：
  — composer.lock 陈旧或版本约束太宽（如 "^2.0"）导致回溯过深
  — 某个包的 dist 地址返回 404（镜像也救不了）
  — 本地 PHP 版本或扩展缺失，触发大量兼容性检查
• 优先用 composer install 恢复已有锁文件，而非无意义地 update
• 真要更新，加 -vvv 看卡在哪一步，别指望换源能解决这个阶段的问题

镜像同步有延迟，新发布的包可能暂时找不到；composer clear-cache 后仍报 404，先查镜像站网页能否搜到该包，再决定是否等几分钟重试。