常见的Composer镜像配置方案对比-composer-PHP中文网

composer config -g repo.packagist 命令总不生效是因为键名必须为单数repo.packagist、type值必须显式写composer、url必须以/结尾，三者缺一即静默失效；验证需输出完整json对象{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}。

常见的composer镜像配置方案对比

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

不是镜像地址失效，而是键名、type 或 URL 格式错得“静默失败”——composer config -g 不报错，但配置根本没写进去。

repo.packagist 是唯一合法键名：写成 repos.packagist（多一个 s）、packagist.org 或大小写混用（如 Repo.Packagist）都会被忽略
composer 是强制 type 值：不能省略，也不能写成 vcs、package 或空字符串
镜像 URL 必须以 / 结尾：https://mirrors.aliyun.com/composer/ ✅，少斜杠会拼出 /composerpackages.json 导致 404 或 fallback 到官方源

验证是否写入成功：运行 composer config -g repo.packagist，输出应为完整 JSON：{"type":"composer","url":"https://mirrors.aliyun.com/composer/"}；如果为空、null 或报错，说明没写对。

项目级 repositories 配置为何比全局更可靠

全局配置只改 ~/.composer/config.json，但只要项目里有 composer.json 且含 repositories 字段，全局就完全被忽略——Composer 不合并，只替换。

CI/CD 容器、宝塔面板、Docker 构建中，~/.composer 往往不存在或属不同用户，全局配置形同虚设
项目级配置必须手动编辑 composer.json，在 repositories 数组首位添加：{"type": "composer", "url": "https://mirrors.huaweicloud.com/repository/php/"}
必须同时在根节点加 "packagist.org": false（注意不是嵌套在 repositories 里），否则 Composer 仍会 fallback 到官方源
改完后删掉 vendor/ 和 composer.lock，再跑 composer install，否则旧 dist URL 仍从 github.com 下载

阿里云、腾讯云、华为云镜像的实际表现差异

三家都同步 packagist.org，但同步策略和 CDN 节点不同，直接影响 composer update 速度和稳定性，不是“谁更快”，而是“谁更匹配你当前网络环境”。

Discussion Composer

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

下载

阿里云（https://mirrors.aliyun.com/composer/）：同步延迟约 5–10 分钟，华北节点快，但华东部分用户偶发 502；适合日常开发，不推荐高频更新依赖的 CI 场景
华为云（https://mirrors.huaweicloud.com/repository/php/）：全量镜像，含历史版本包，同步延迟最低；但 metadata 请求略慢（因分片存储）
腾讯云（https://mirrors.cloud.tencent.com/composer/）：CDN 覆盖广，南方用户稳定，但不保留已删包；遇到 Package not found 可能是原包被作者下架，非镜像问题

测试方法很简单：清缓存后跑 time composer update --dry-run，重点看是否出现 Connection refused 或 SSL certificate problem——后者多因镜像用了自签名证书或过期中间证书。

为什么配了镜像还是卡在 Downloading https://api.github.com/

因为镜像只加速元数据（packages.json、p2/xxx.json），不代理 zip 包下载。实际 dist 文件仍从 GitHub 直连，这才是真瓶颈。

composer install -vvv 日志里反复出现 Downloading https://api.github.com/ 或 https://codeload.github.com/ → 镜像没起作用
元数据加载飞快（mirrors.aliyun.com/composer/），但某个包卡住 30 秒以上 → 八成是 GitHub 直连问题
企业级方案：部署 satis 或 toran proxy；个人开发更推荐直接用 ghproxy.com 类型的反向代理
临时加 --repository 参数对已存在的 composer.lock 无效：lock 文件里记录的是旧 dist URL，Composer 就会照单下载，无视任何镜像配置