解决Composer install命令卡在loading部分的实用方法-composer-PHP中文网

composer config -g repo.packagist 未生效是因为键名必须为单数 repo.packagist、type 值必须显式写 composer、url 必须 https 且末尾带 /，三者缺一即静默回退官方源；验证需输出完整 json 如 {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}。

解决composer install命令卡在loading部分的实用方法

composer config -g repo.packagist 命令为什么没生效

它根本没写进配置，但也不报错——这是最常被忽略的“静默失败”。repo.packagist 键名写成 repos.packagist（多一个 s）、漏掉中间的 composer type 值、URL 少了末尾 /，三者任一出错，Composer 就自动 fallback 到 https://packagist.org，且日志里完全不提示。

验证是否真写进去了，只看这一行输出：
composer config -g repo.packagist
必须返回完整 JSON：{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}，或至少是带结尾斜杠的 URL 字符串。返回 null、空、Key not found 或仍含 packagist.org，说明配置压根没成功。

卡在 Loading composer repositories 的真实原因

这一步不是在下载包，而是在拉取全量元数据文件 packages.json。默认走海外地址，DNS 解析慢、TLS 握手不稳定、首字节延迟高，国内直连成功率极低。

镜像源必须同时提供元数据接口和 ZIP 包分发节点，且两者 URL 路径结构一致。比如阿里云地址是 https://mirrors.aliyun.com/composer/，那它下面的 packages.json 和后续每个包的 dist 下载路径都得能拼出来。少个 / 就会变成 /composerpackages.json，直接 404。

手动验证镜像连通性：curl -I https://mirrors.aliyun.com/composer/packages.json，必须返回 200 OK
运行 composer install -vvv，盯住第一行日志：必须出现 Downloading https://mirrors.aliyun.com/composer/packages.json
如果日志里还看到 packagist.org/packages.json，说明全局配置被覆盖或失效

项目级配置比全局更可靠

全局配置写在 ~/.composer/config.json，但在 Docker、宝塔、GitHub Actions 等环境里，执行用户（如 www-data 或 runner）往往读不到你的配置。项目级配置直接写进 composer.json，随代码提交，行为确定。

进项目根目录后执行：
composer config repo.packagist composer https://mirrors.tuna.tsinghua.edu.cn/composer/（注意不加 -g）

Discussion Composer

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

下载

这条命令会安全追加到 composer.json 的 repositories 字段中，不覆盖已有私有源。但要注意：

如果 composer.json 原来是 "repositories": []（数组），命令会失败；需先改成 "repositories": {}（对象）
已有私有仓库时，别手写 JSON——引号或逗号错一个，composer install 就直接报语法错误
改完后必须删掉 vendor/ 和 composer.lock，否则旧 lock 文件里的哈希与镜像站元数据不匹配，会报 signature mismatch