composer config --list 显示的是五层配置（命令行参数、环境变量、项目、全局、默认值）叠加后最终生效的快照，且仅列出显式设置的项；要查来源需用 --show-source。
composer config --list 看到的到底是谁在说话？
它显示的是**最终生效的配置快照**，不是你项目 composer.json 里写的那几行——而是命令行参数、环境变量、项目配置、全局配置、默认值五层叠加后“胜出”的结果。
-
composer config --list默认只显示被显式设置过的项（比如你改过vendor-dir，它才出现；没动过的bin-dir就不列） - 优先级顺序是：
命令行参数 > 环境变量（如 COMPOSER_CACHE_DIR）> 项目 composer.json > 全局 ~/.composer/config.json > Composer 内置默认值 - 常见错觉：看到
cache-dir: null就以为“没设”，其实只是所有层级都没显式定义，Composer 会 fallback 到默认路径（~/.composer/cache） - 如果
process-timeout: 0，别急着删——这通常是 CI 脚本里故意关掉超时的，不是配置写错了
怎么知道某个配置值从哪来的？
用 composer config --show-source key.name，比如查缓存目录来源：composer config --show-source cache-dir，输出会明确标出是 project、global 还是 default。
- 想一次性看全所有配置及其来源？用
composer config --dump-keys --show-source（注意不是--list） - 这个命令能帮你快速定位冲突：比如本地
composer.json设了github-oauth，但环境变量又覆盖了，--show-source会直接告诉你哪一行/哪个文件赢了 -
--show-source不支持--global参数，它天然区分作用域；要单独看全局配置内容，还是得用composer config --list --global
查配置别只盯着 --list，它不报错也不提醒你踩坑
composer config --list 是个“哑巴快照”：它告诉你结果，但从不说谁改的、什么时候改的、有没有被环境变量悄悄覆盖。
- 排查缓存异常？别光看
cache-dir值，先跑env | grep COMPOSER，检查COMPOSER_CACHE_DIR是否被 shell 设置过 - 想确认 autoload 是否生效？
composer show -s vendor/package-name比翻composer.json更准，它读的是实际安装后的解析结果 - 输出里有
github-oauth: null？不代表没授权——可能只是没显式配置，但~/.composer/auth.json里还躺着 token - CI 环境下
composer install卡住？先查composer config --list | grep timeout，process-timeout: 0是正常操作，但0和没设是两回事
全局配置和项目配置混着查，容易漏关键项
很多人只运行 composer config --list，却不知道它默认**完全不展示全局配置里没被项目覆盖的项**——比如你全局设置了 github-oauth，但项目里没动它，--list 就不会显示。
- 查全局到底设了啥？必须加
--global：composer config --list --global - 想对比项目 vs 全局差异？手动执行两次再
diff，没有一键命令 - 全局包装在哪？
composer global show才是正解，不是composer show；后者只查当前项目已安装的包 -
composer global show --direct可过滤掉依赖自动带进来的包，只留你主动require的工具
--show-source，靠记忆不如留好注释。最常被忽略的其实是环境变量那一层——它不写在任何 JSON 文件里，却能在你毫无察觉时接管整个配置链。 
