Composer全局配置会被项目级composer.json同名字段完全覆盖，无合并逻辑；repositories等字段静默替换，需显式复用；调试应使用composer config --list --global与composer config --list对比。

Composer 全局配置（~/.composer/config.json）的设置，**会被项目级 composer.json 中同名字段完全覆盖**，不存在“合并”或“继承”逻辑——这是最常被误解的一点。

全局 config.json 和项目 composer.json 的字段如何生效

Composer 读取配置时按顺序加载：全局 → 项目根目录 → 命令行参数。但关键在于：**相同配置项只保留最后出现的那个值，不会叠加**。

• repositories 字段：项目级会完全替换全局定义，不是追加。若想复用全局仓库，必须在项目 composer.json 中显式写入或使用 composer config repositories. 手动添加
• config 下的子项（如 vendor-dir、bin-dir）：项目级 "config": {"vendor-dir": "lib/vendor"} 会彻底屏蔽全局的 vendor-dir 设置
• fxp-asset、github-oauth 等认证类配置：全局设置仍有效，因为它们不属于项目 composer.json 合法字段，不会被覆盖

修改全局配置的实际命令与风险

用 composer config -g 操作的是 ~/.composer/config.json，但要注意：

• 执行 composer config -g repo.packagist composer https://packagist.org 会重写整个 repositories 数组，清空你之前加的私有仓库
• 全局 config.json 不支持注释，手动编辑易因格式错误导致后续所有 composer 命令失败（报错类似 file_get_contents(): Failed to open stream: No such file or directory）
• CI/CD 环境中依赖全局配置是危险的——它不可重现、不随代码提交，应改用项目级 composer.json + COMPOSER_AUTH 环境变量管理凭证

调试配置优先级的可靠方法

别猜，直接看 Composer 解析后的最终结果：

composer config --list --global

composer config --list

这两条命令分别输出全局和当前项目的**实际生效配置**（已解析、已展开、无继承）。对比二者差异，就能立刻确认哪个值胜出。

特别注意：composer config --list 在项目目录下运行时，显示的是“项目级配置 + 全局未被覆盖的部分”，但它**不告诉你某个字段是否来自全局**——所以必须两边都跑一遍再逐项比对。

真正容易被忽略的，是 repositories 这种数组型配置的覆盖行为：它不报错、不警告，静默替换成项目级定义，可能导致私有包安装失败却查不出原因。