Composer局部配置覆盖全局？项目级别镜像配置方法【教程】-composer-PHP中文网

项目级配置会完全屏蔽全局镜像，前提是composer.json中正确设置"packagist.org": false、repositories为数组且含合法packagist对象，url末尾必须带斜杠。

composer局部配置覆盖全局？项目级别镜像配置方法【教程】

项目级配置会直接覆盖全局镜像

只要项目根目录下 composer.json 里存在 repositories 字段，无论内容是否为空、是否只写了 {"packagist.org": false}，Composer 就会彻底忽略 ~/.composer/config.json 里的 repo.packagist 配置。这不是“优先级更高”，而是“完全屏蔽”——全局设置形同虚设。

常见错误现象：composer config -g repo.packagist 显示已设阿里云地址，但 composer install 日志里仍出现 packagist.org 域名；或执行 composer diagnose 时输出 Repo packagist.org is default。

检查方式：运行 grep -A10 "repositories" composer.json，确认是否存在该字段
临时验证：进项目目录后执行 composer config --unset repositories（不加 -g），再跑 composer install，看是否切回全局镜像
注意：删掉 composer.json 中的 repositories 后，必须同时删掉 vendor/ 和 composer.lock，否则旧 lock 文件会继续走原源

正确写法：repositories 数组 + packagist.org: false

项目级镜像不是往 repositories 里随便塞个 URL 就行。必须满足三个硬性条件：一是 repositories 是数组，二是其中包含一个 "packagist": {"type": "composer", "url": "https://mirrors.aliyun.com/composer/"} 对象，三是顶层键 "packagist.org": false（不是放在 repositories 里面）。

错误示例："repositories": {"packagist.org": false} —— 这是对象而非数组，且 packagist.org 放错位置；"repositories": [{"type": "composer", "url": "https://mirrors.aliyun.com/composer"}] —— 缺少 "packagist.org": false，结果仍是兜底请求官方源。

Discussion Composer

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

下载

正确结构节选：

{
    "packagist.org": false,
    "repositories": [
        {
            "packagist": {
                "type": "composer",
                "url": "https://mirrors.aliyun.com/composer/"
            }
        }
    ]
}

url 末尾必须带 /，https://mirrors.aliyun.com/composer/ ✅，https://mirrors.aliyun.com/composer ❌（会拼出 packages.json 路径导致 404）
若项目原本已有私有源（如 Git VCS 源），不要用 composer config repo.packagist 命令——它会清空整个 repositories 数组，必须手动编辑 JSON

CI/CD 和多用户环境慎用全局配置

在宝塔、Jenkins 或 systemd 服务中，composer config -g 写的是当前 shell 用户的 ~/.composer/config.json，但实际执行命令的可能是 www、jenkins 或 root 用户。你本地配好了，CI 流水线照样连 packagist.org。

排查方法：在构建脚本开头加 whoami && echo $HOME，再检查对应路径下 $HOME/.composer/config.json 是否存在且含正确配置；若用 sudo composer config -g，很可能写进了 root 的配置，而构建进程以普通用户身份运行，压根读不到。

CI 推荐做法：不用全局配置，改用环境变量 COMPOSER_REPO_PACKAGIST=https://mirrors.aliyun.com/composer/，或直接在命令中加参数 --repository-url=https://mirrors.aliyun.com/composer/
宝塔面板里 PHP 管理器的「一键部署」功能，底层调用的是 www 用户，需用该用户身份执行 composer config -g 才生效
团队协作时，项目级配置写死在 composer.json 里，能避免成员本地环境不一致导致 composer.lock 差异和安装失败

验证是否真走镜像，别信 config 输出

composer config -g repo.packagist 输出 URL 只说明配置写入成功，不代表请求真的发到了镜像站。最可靠的方式是看网络请求日志。

执行 composer clear-cache && composer require monolog/monolog -vvv 2>&1 | grep -i "get\|downloading"，观察输出中是否出现 mirrors.aliyun.com 或其他镜像域名。如果看到 packagist.org 或 repo.packagist.org，说明配置没起作用。

关键线索藏在 -vvv 日志里，比如 Downloading https://mirrors.aliyun.com/composer/p2/monolog/monolog.json
某些 IDE（如 PHPStorm）会缓存 Composer 配置，改完全局设置后需重启 IDE 才能识别
PHP 环境若禁用了 proc_open 或 putenv（常见于宝塔或共享主机），composer config -g 会静默失败，需检查 php.ini 并重启 PHP 服务