Composer如何配置config选项_Composer config选项配置教程

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及以上版本中，使用http://开头的地址会被直接拒绝，务必写成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