Composer配置的“潜规则”：为什么你的config选项总是不生效？
先划个重点：所有config选项都必须通过composer config命令来设置，手动编辑JSON文件是无效的。项目级配置要写入composer.json根目录的config字段，而全局配置则必须加上--global（或简写-g）参数。这里的关键在于，一旦键名写错或者位置放错，整个配置就等于白费功夫。
config键名写错或放错位置，配置完全不生效
你是不是也遇到过这些情况：明明改了配置，composer install却还是走官方源，速度慢得让人心焦；github-oauth设好了，但API限流提示依然弹个不停；打开了sort-packages，依赖列表却纹丝不动，毫无排序的迹象？问题很可能就出在配置的“书写规范”上。
- 首先，
config字段必须老老实实待在composer.json文件的最外层。如果把它塞进了require、scripts或者extra这些“邻居”家里，Composer会直接视而不见。 - 其次，所有键名都必须是官方文档里白纸黑字定义好的。比如
sort-packages是合法选项，但你心血来潮写个my-custom-flag进去，Composer虽然不会报错，但也绝对不会理睬。 - 再者，嵌套对象只支持特定的结构。例如，在
github-oauth下面写{"github.com": "token"}是没问题的，但如果你自己构造一个像{"foo": {"bar": true}}这样的多层嵌套，整个配置块都会被直接跳过。 - 最后，修改配置后，别忘了运行
composer install或composer update来让新配置生效。这里有个常见的误解：这个命令本身并不负责“读取”config，它影响的是后续命令执行时的行为逻辑。
哪些config必须用--global？凭据类配置不支持项目级
涉及到认证信息的配置，比如GitHub、GitLab或者私有仓库的令牌，Composer有一个非常明确的规定：只认全局配置。如果你试图在项目级的config字段里写入github-oauth或http-basic，结果只会是徒劳无功。
- 正确的姿势是：
composer config --global github-oauth.github.com "your_token"（注意，令牌值最好用引号包裹，防止空格被意外截断）。 - 配置私有仓库的HTTP认证：
composer config --global http-basic.repo.example.com username password。 - 添加GitLab域名白名单：
composer config --global gitlab-domains '["gitlab.internal.company"]'（这里有个细节：JSON数组需要用单引号整体包裹起来）。 - 如果把这类敏感配置误设在了项目级，不仅每次执行
composer install都会卡在身份验证的提示上，更危险的是，一旦把composer.json提交到Git仓库，就等于公开泄露了你的密码。
镜像源配置别混淆repo.packagist和repos.packagist
对于国内开发者来说，镜像源配置是个高频踩坑区。键名拼错、协议写错、忘了清缓存，都会导致“明明配了镜像，下载速度却一点没提上来”的尴尬局面。
- 设置全局镜像，必须使用
composer config --global repos.packagist（注意是repos，复数形式）。早期文档里出现的repo.packagist（单数）写法现在已经废弃了。 - 配置的值必须是一个对象格式：
composer config --global repos.packagist '{"type": "composer", "url": "https://mirrors.aliyun.com/composer/"}'。 - 协议方面，HTTPS现在是强制要求。在Composer 2.2及以上版本中，使用
https://开头的地址会被直接拒绝，务必写成https://。 - 修改镜像源之后，记得立刻执行
composer clear-cache。否则，旧的包索引可能还残留在缓存里，让你误以为新配置没有生效。
vendor-dir、bin-dir改了不会自动迁移文件
这两个路径配置的作用，仅仅是告诉Composer“下次安装依赖时，请放到这个新位置”。它们不会自动帮你移动已经存在的vendor/或bin/目录里的文件，盲目修改很容易导致自动加载失败或者命令行工具找不到。
- 安全的操作顺序是：首先，手动删除旧的
vendor/和bin/目录（操作前请确认没有自定义脚本硬编码引用了这些旧路径）。 - 然后，再执行配置命令，例如项目级设置：
composer config vendor-dir "third-party"，或全局设置：composer config --global vendor-dir "/shared/vendor"。 - 最后，运行
composer install，依赖才会被安装到新的目标路径中。 - 对于Lara vel这类框架，如果入口文件手动引入了
vendor/autoload.php
还有一个最容易被忽略的要点：Composer的config并非“即时生效的开关”。它只在执行具体命令时参与决策。举个例子，process-timeout配置影响的是composer install命令的超时判断，而不是config本身的加载过程；platform配置可以“伪装”PHP版本，但这只改变依赖解析的结果，并不会改变实际的运行时环境。这类行为上的细微差异，如果不查看详细日志或者使用composer why-not这类诊断命令，很难被察觉到。
