composer config --list 显示的是分层合并后的最终生效配置，而非仅项目 composer.json 内容；优先级为命令行参数 > 环境变量 > 项目配置 > 全局配置 > 默认值，故常与 composer.json 不一致。
composer config --list 是查看当前 Composer 配置最直接的方式，但它输出的不是“当前项目配置”而是“生效的完整配置叠加结果”——包括全局配置、项目配置、环境变量覆盖等。很多人误以为它只显示 composer.json 里的 config 字段，实际并非如此。
为什么 composer config --list 显示的配置和 composer.json 不一致？
Composer 的配置是分层合并的，优先级从高到低为：命令行参数 > 环境变量（如 COMPOSER_HOME） > 当前项目 composer.json > 全局 config.json（通常在 ~/.composer/config.json） > 默认内置值。执行 --list 时，它展示的是最终生效值，而非来源。
- 如果在项目根目录执行，
vendor-dir可能显示./vendor，但你没在composer.json里写，说明它来自全局或默认值 - 若看到
github-oauth或http-basic出现在列表中，大概率是通过composer config --global设置过凭据 -
process-timeout默认是 300，但如果被设成 0，说明有人显式禁用了超时（常见于 CI 环境）
如何确认某项配置到底来自哪个文件？
Composer 没有原生命令直接溯源，但可通过排除法定位：
- 运行
composer config --list --no-plugins排除插件干扰 - 临时重命名全局配置：
mv ~/.composer/config.json ~/.composer/config.json.bak，再执行--list，对比变化项 - 检查项目级配置是否被
.env或 shell 环境变量覆盖：比如export COMPOSER_CACHE_DIR="/tmp/composer-cache"会让cache-dir显示该路径 - 用
composer config --list | grep -E "^(cache-dir|vendor-dir|github-oauth)"快速筛选关键项
composer config --list 常见误用与陷阱
这个命令本身不校验配置合法性，也不会提示冲突。几个高频问题：
- 输出中出现
null值（如bin-dir: null），通常表示该字段未被任何层级设置，Composer 将使用内置默认值（bin-dir默认是vendor/bin） - 在 Git Bash 或 Windows CMD 下，中文路径可能显示为乱码或截断，建议改用 WSL 或 PowerShell 查看
- 如果项目使用了
composer.lock且含plugin-api-version，某些旧版 Composer（--list 报错退出，此时需升级 Composer -
--list不反映运行时动态修改（如通过putenv("COMPOSER_HOME=...")在 PHP 脚本中改环境变量），仅反映命令启动时的环境
真正要调试配置问题，别只盯着 --list 输出——它像一张快照，告诉你“结果是什么”，但不会说“谁写的、什么时候写的、有没有被覆盖”。尤其在团队协作或 CI/CD 场景下，环境变量和全局配置的隐式影响远比 composer.json 里的几行更难排查。
