composer全局配置仅作兜底，不能覆盖项目级配置；项目composer.json中的config字段会完全屏蔽同名全局设置，仅github-oauth、http-basic等认证类配置支持叠加生效。
composer config --global 不能覆盖项目级配置——它只能兜底，不能强制覆盖。
项目根目录下的 composer.json 中的 "config" 字段会完全替换全局配置，不是合并，也不是“优先级更低所以被忽略”。想让某个设置在所有项目里都生效？别指望全局 config 能压过项目自己的声明。
composer.json 里的 config 会彻底屏蔽全局同名项
- 全局设了
cache-dir，但项目composer.json里写了"cache-dir": "vendor/cache"，那最终就是后者，全局值被丢弃 - 同理，
process-timeout、bin-dir、github-oauth（注意：这个是例外，见下条）等，只要项目显式定义，就无条件生效 - 唯一不被项目覆盖的，是认证类配置：
github-oauth、http-basic等，它们支持多源叠加，项目可额外加，不会删掉全局的
常见错误现象：
- 改了
composer config --global cache-dir，但composer install还是往默认位置写缓存
→ 检查项目composer.json是否有"cache-dir"字段 - 设了全局
repos.packagist，但项目仍走 packagist.org 官方源
→ 项目里可能写了"repositories": [{"type": "composer", "url": "@#@#@#@#@#@#@#@#@#@0"}]，这会完全取代全局仓库配置
哪些全局配置真能“穿透”到项目里？
真正能跨项目生效的，仅限与「环境行为」强相关、且 Composer 明确设计为可继承的项：
工作流任务拆解与模型编排技能。使用场景：(1) 收到复杂工作任务需要拆解为可执行步骤，(2) 需要为不同步骤选择最合适的模型，(3) 需要跟踪工作流进度和模型使用情况，(4) 长时间任务卡住需要问题诊断和解决方案。
-
github-oauth：多个 token 可共存，全局 + 项目 = 全部可用 -
http-basic：同上，用于私仓认证，叠加有效 -
process-timeout：若项目没设，就用全局值；设了就用项目的 -
cache-dir、data-dir、home：只影响全局命令上下文（如composer global require），不干预项目 install/update 流程中的路径选择
但注意：minimum-stability、prefer-stable、platform 这类策略项，即使全局设了，在空目录下运行 composer require 也不会自动应用。它们只在 create-project 或项目已有 composer.json 且未覆盖时才继承。
如何验证某项到底用了谁的值？
直接运行：
composer config --list
它会列出所有生效项，并在每行末尾标注 (global) 或 (local)。
不要看 ~/.composer/config.json 文件内容——那只是“你设过什么”，不代表“当前生效什么”。
如果某项既出现在全局又出现在项目级，且值不同，composer config --list 输出中带 (local) 的那个才是实际起作用的。
全局配置不是控制中心，而是 fallback 机制。真正要统一管理多个项目的配置，得靠模板 composer.json、CI 脚本注入，或者用 composer create-project 配合自定义 skeleton。硬靠 --global 去“覆盖”局部，从设计上就行不通。
