composer config --list 显示的配置来自四层合并：项目级（composer.json）、用户级（~/.composer/config.json）、全局级（composer_home）和内置默认值，优先级从高到低覆盖；仅显式设置的项才显示，内置默认值需用 composer config key-name 查看。
composer config --list 显示的配置到底从哪来
它不是只读当前项目的 composer.json，而是合并了四层来源：项目级（composer.json）、用户级（~/.composer/config.json）、全局级（COMPOSER_HOME 指向位置）、以及 Composer 内置默认值。优先级从高到低，同名配置会被覆盖。
常见错误现象：composer config --list 里看到某个 github-oauth token，但自己项目里没写——大概率是用户级配置里塞的；或者改了项目 composer.json 的 repositories，却没生效，其实是被更高优先级的全局配置挡住了。
- 用
composer config --list --global单独看用户级配置 - 用
composer config --list --file composer.json强制只读项目文件（跳过合并） - 想确认某项是否被继承，加
-v参数，会标出每行配置的来源文件路径
为什么有些配置项在 --list 里不显示
不是所有设置都会列出来。composer config --list 默认只显示「显式设置」的项，比如你手动执行过 composer config github-oauth.github.com xxx 或在 composer.json 里写了 "config": { "process-timeout": 3600 }，它才出现。
内置默认值（如 bin-dir 默认是 vendor/bin，cache-dir 默认是 ~/.composer/cache）不会显示，除非你主动改过。
- 想知道某个默认值实际是多少，直接查文档或运行
composer config bin-dir（不带--list） -
composer config --list不会列出插件定义的配置项，哪怕插件已启用 - 某些敏感字段（如
github-oauth）在输出中会被星号掩码，但依然算“已设置”
修改配置前必须注意的三个兼容性点
Composer 2.x 对配置结构更严格，尤其涉及 repositories 和 config 的嵌套逻辑。乱改可能让 install 直接失败，而不是报错提示。
-
repositories数组里不能混用packagist类型和vcs类型——Composer 2.2+ 会拒绝加载整个配置 -
http-basic配置必须是对象，不能是字符串；写成"http-basic": {"repo.example.com": "user:pass"}会报错，得拆成{"repo.example.com": {"username": "user", "password": "pass"}} - Windows 下路径类配置（如
cache-dir）如果用了反斜杠\而没转义，composer config --list可能显示异常甚至解析失败
快速验证某项配置是否生效的实操方法
别只信 --list 输出，要结合实际命令行为判断。比如改了 fxp-asset-plugin 相关配置，--list 看到了，但 composer update 还走 GitHub API，说明没生效。
- 执行
composer config <code>key-name（不带--list）直接读单个值，最准 - 运行
composer diagnose，它会检查配置合法性，并提示冲突或废弃项 - 临时加
-vvv跑一次composer install，日志里会打印最终解析出的完整配置快照
