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 这种数组型配置的覆盖行为：它不报错、不警告，静默替换成项目级定义，可能导致私有包安装失败却查不出原因。
