Composer安装多仓库配置？同时引用Git与Zip源-composer-PHP中文网

repositories必须是索引数组，不能写成对象；顺序即优先级，命中即停；{"packagist.org": false}须单独成项；type需匹配vcs/composer/package，认证凭据必须通过auth.json配置。

composer安装多仓库配置？同时引用git与zip源

repositories数组必须是索引数组，不能写成对象

很多人复制配置时把 repositories 写成键值对（比如 {"my-vcs": {"type": "vcs", "url": "..."} }），结果只有最后一个仓库生效，甚至完全不识别。Composer 只认标准 JSON 数组："repositories": [ {...}, {...} ]，且严格从左到右扫描。

常见错误现象：加了两个私有源，但 composer require myorg/foo 总是从第二个源拉——其实是第一个源因格式错误被跳过，只剩第二个生效。

✅ 正确写法："repositories": [ {"type": "vcs", "url": "https://gitlab.com/myorg/foo.git"}, {"type": "composer", "url": "https://packages.mycompany.com"} ]
❌ 错误写法："repositories": { "vcs": { "type": "vcs", ... }, "composer": { "type": "composer", ... } }
⚠️ 特别注意：{"packagist.org": false} 必须作为独立数组项，不能塞进任意一个仓库对象里

type选vcs还是composer，决定包能不能被发现

vcs 类型只对 require 中**明确写出的包名**起作用；composer 类型则提供完整索引，支持搜索、版本解析和依赖推导。想同时用 Git 仓库和 Zip 包，得看你要怎么用它们。

典型场景：你有一个内部工具库托管在 GitLab，同时想引用某第三方闭源组件（只提供 ZIP 下载链接）——前者用 vcs，后者必须用 package 类型手动声明。

vcs：URL 指向 Git/SVN/Hg 仓库地址，Composer 会 clone 并读取其根目录下的 composer.json；仅当你 require myorg/tool 且该仓库恰好叫 myorg/tool 时才匹配
package：需手动写死包名、版本、dist.url（ZIP 地址）、autoload 等字段，适合单点分发，不参与全局索引
混用没问题，但别指望 vcs 仓库里的包能被 composer search 扫到，它不提供 packages.json

Git源要能 clone，Zip源要能下载，两者认证方式不同

Git 源走 SSH 或 HTTPS+Token，Zip 源走 HTTP Basic 或 bearer token，但所有凭据都必须放在 auth.json，绝不能写进 composer.json。

Git Pushing

使用约定式提交信息暂存、提交和推送git更改。当用户想要提交和推送更改、提到推送到远程、或要求保存并推送工作时触发。也适用于用户说“推送更改”、“提交并推送”、“推送这个”、“推送到github”或类似git工作流程请求时。

下载

常见卡点：GitLab 私仓返回 401，或 ZIP 下载返回 403——不是 URL 错，而是 auth.json 格式或位置不对。

Git SSH 方式：auth.json 不起作用，得靠系统 ssh-agent 或 ~/.ssh/config；HTTPS 方式则填 "gitlab.com": {"http-basic": {"username": "token", "password": "xxx"}}
ZIP 下载若需 header 认证（如 Authorization: Bearer xxx），Composer 原生不支持，得改用 package + dist.options.headers（需 Composer 2.5+）
auth.json 必须放在项目根目录或 ~/.composer/，且权限应为 600，否则 Composer 会忽略

composer install 不更新源配置，必须触发 lock 重生成

composer install 完全信任 composer.lock 里记录的 dist URL 和 commit hash，哪怕你刚改完 repositories，它也不会重新查源。这就是为什么改了 Git 地址或加了 ZIP 包，install 还是旧行为。

正确做法不是删 lock 文件（生产环境危险），而是让 Composer 重解析源并更新 lock 里的元数据：

运行 composer update --lock：只更新 lock 文件中的源信息、URL、reference，不改动已安装包
如果要强制走新 Git 分支，且该分支在 lock 里没记录，得先 composer remove myorg/foo，再 composer require myorg/foo:dev-new-branch
对 package 类型 ZIP 包，首次 require 后，后续 install 仍会从 lock 记录的 URL 下载——换 ZIP 地址必须 update --lock 或删 lock

真正容易被忽略的是：vcs 源和 package 源在依赖解析阶段就分道扬镳——前者靠仓库自动发现，后者靠你手写的每个字段。配错一个字段（比如 dist.type 写成 zip 却没写 dist.url），composer require 就直接报 Could not find package，连请求日志都不会发出去。