composer config --list 显示的配置来自四层合并：项目级（composer.json）、用户级（~/.composer/config.json）、全局级（COMPOSER_HOME）和内置默认值，优先级从高到低覆盖；仅显式设置的项才显示，内置默认值需用 composer config key-name 查看。
composer
config --list 显示的配置到底从哪来
它不是只读当前项目的
，而是合并了四层来源：项目级（
）、用户级（
）、全局级（
指向位置）、以及 Composer 内置默认值。优先级从高到低，同名配置会被覆盖。
常见错误现象：
里看到某个
token，但自己项目里没写——大概率是用户级配置里塞的；或者改了项目
的
，却没生效，其实是被更高优先级的全局配置挡住了。
用
单独看用户级配置
用
强制只读项目文件（跳过合并）
想确认某项是否被继承，加
参数，会标出每行配置的来源文件路径
为什么有些配置项在 --list 里不显示
不是所有设置都会列出来。
默认只显示「显式设置」的项，比如你手动执行过
或在
里写了
，它才出现。
内置默认值（如
默认是
，
默认是
）不会显示，除非你主动改过。
Composer 2.9.6
Composer 2.9.6 是 PHP 生态中高效、稳定的依赖管理工具。此版本在性能与兼容性上进一步优化，改进了依赖解析算法，提升大型项目中的安装与更新速度。它支持并行下载任务，显著减少等待时间，并增强了与私有仓库及镜像源的交互稳定性。同时修复了多项命令行交互与内存使用相关的缺陷，确保在复杂依赖关系下依然可靠运行。无论是新项目初始化还是现有系统维护，Composer 2.9.6 都能为开发者提供流畅、精准的依赖管理体验。
下载
想知道某个默认值实际是多少，直接查文档或运行
（不带
）
不会列出插件定义的配置项，哪怕插件已启用
某些敏感字段（如
）在输出中会被星号掩码，但依然算“已设置”
修改配置前必须注意的三个兼容性点
Composer 2.x 对配置结构更严格，尤其涉及
和
的嵌套逻辑。乱改可能让
直接失败，而不是报错提示。
数组里不能混用
类型和
类型——Composer 2.2+ 会拒绝加载整个配置
配置必须是对象，不能是字符串；写成
会报错，得拆成
Windows 下路径类配置（如
）如果用了反斜杠
而没转义，
可能显示异常甚至解析失败
快速验证某项配置是否生效的实操方法
别只信
输出，要结合实际命令行为判断。比如改了
相关配置，
看到了，但
还走 GitHub API，说明没生效。
执行
（不带
）直接读单个值，最准
运行
，它会检查配置合法性，并提示冲突或废弃项
临时加
跑一次
，日志里会打印最终解析出的完整配置快照
配置的叠加逻辑和隐藏默认值是最大复杂点，很多人卡在“明明改了却没用”，其实只是没意识到自己改的是哪一层。
composer.jsoncomposer.json~/.composer/config.jsonCOMPOSER_HOMEcomposer config --listgithub-oauthcomposer.jsonrepositoriescomposer config --list --globalcomposer config --list --file composer.json-vcomposer config --listcomposer config github-oauth.github.com xxxcomposer.json"config": { "process-timeout": 3600 }bin-dirvendor/bincache-dir~/.composer/cachecomposer config bin-dir--listcomposer config --listgithub-oauthrepositoriesconfiginstallrepositoriespackagistvcshttp-basic"http-basic": {"repo.example.com": "user:pass"}{"repo.example.com": {"username": "user", "password": "pass"}}cache-dir\composer config --list--listfxp-asset-plugin--listcomposer updatecomposer config key-name--listcomposer diagnose-vvvcomposer install