常用开发者工具中的Composer镜像配置-composer-PHP中文网

composer config -g repo.packagist 静默失效是因为未同时满足三个硬性条件：键名必须为单数 repo.packagist、type 值必须显式写 composer、url 必须 https 且末尾带 /；任一缺失即回退官方源，验证需输出完整 json 对象。

常用开发者工具中的composer镜像配置

配不成功不是网络慢，是命令写错了三个硬性条件——漏掉任意一个，composer config -g repo.packagist 就会静默失败，不报错、不提示、也不生效。

为什么 `composer config -g repo.packagist` 总是“看起来执行了，实际没用”

它不报错，但 composer install 依然卡在 Loading composer repositories，说明配置根本没写进去。常见原因有：

repo.packagist 拼错成 repos.packagist（多一个 s）、packagist.org 或大小写混用（如 Repo.Packagist），全部被 Composer 忽略
漏掉中间的 composer 参数——这不是可选注释，而是强制 type 值；省略后直接 fallback 到官方源
镜像 URL 少了末尾斜杠：https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（会拼出 /composerpackages.json 导致 404）
用了 HTTP 协议：Composer 2.0+ 拒绝非 HTTPS 镜像地址

验证是否真的写进去了，别信“执行完就 OK”

最可靠的方式是立刻运行：

composer config -g repo.packagist

输出必须是完整 JSON 对象，例如：

Discussion Composer

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

下载

{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}

如果返回空、null、Key does not exist，或仍是 https://packagist.org，说明没写成功。这时要检查：

是否用了 sudo 执行，但日常开发是普通用户？配置写到了 root 的 ~/.composer/config.json，而你读的是自己的
Linux/macOS 下 ~/.composer 目录归属不是当前用户？运行 chown -R $USER ~/.composer 再试
想确认实际走哪个源？运行 composer diagnose，看 “Repo.packagist.org” 这一行显示的 URL

项目级配置比全局更可靠，尤其在团队和 CI 场景

全局配置只对当前 shell 用户生效，在宝塔（www 用户）、GitHub Actions（runner 用户）、Docker 容器里根本读不到。项目级才是协作前提：

进项目根目录（含 composer.json），执行：composer config repo.packagist composer https://mirrors.aliyun.com/composer/（注意去掉 -g）
该命令会自动向 composer.json 的 repositories 字段追加结构，key 固定为 "packagist"，不会覆盖已有私有源
如果 composer.json 已有 "repositories": []（空数组），命令会报错；需先手动改成 "repositories": {}（空对象）再重试
改完必须删掉 vendor/ 和 composer.lock，再跑 composer install（不是 update），否则旧 lock 文件仍指向海外源

换源后还卡在 `Resolving dependencies`？那和镜像无关

镜像只加速包下载，不参与依赖解析。卡在这里是本地环境或 composer.json 写法问题：

"php": "^7.4 || ^8.0" 这类宽泛约束会让 Composer 尝试大量版本组合，拖慢解析
require-dev 里塞了太多未锁定版本的工具（如 "phpunit/phpunit": "^10.0"）
用了大量 dev-main 或 dev-develop 分支依赖
PHP CLI 环境本身有问题：检查 proc_open 和 putenv 是否被禁用（宝塔常见），运行 php -i | grep disable_functions 确认