Composer报“Invalid repository URL”是因为URL协议不在默认白名单（仅https、git等），SSH地址需写为git+ssh://格式，且非法URL会导致全部仓库校验失败。
为什么 composer.json 里写对了 URL 还报 “Invalid repository URL”？
Composer 校验仓库 URL 时，不只看格式是否像 URL，还会尝试解析协议、检查 scheme 是否被允许。常见坑是用了 git@github.com:user/repo.git 这类 SSH 地址，但 Composer 默认只信任 https 和 git（注意：不是 git+ssh）等白名单协议。
- 如果你用的是私有 GitLab 或自建 Gitee，URL 写成
<a href="https://www.php.cn/link/e5c1adb54b5221216d74a67f1e6982ec">https://www.php.cn/link/e5c1adb54b5221216d74a67f1e6982ec</a>没问题；但写成git@gitee.com:user/pkg.git就会直接触发该错误 -
ssh://git@gitlab.example.com:2222/user/pkg.git也属于非法 scheme（ssh://不在默认白名单） - 即使加了
"type": "vcs"，只要 URL 协议不合法，校验阶段就失败，根本不会走到克隆逻辑
怎么让 Composer 接受自定义协议或 SSH 地址？
得在 composer.json 顶层加 "repositories" 配置，并显式声明允许的协议类型，不能只靠 URL 推断。
- 在
"repositories"数组中，为每个自定义仓库单独写一项，必须包含"type": "vcs"和完整合法的"url" - 若坚持用 SSH，把 URL 改成
"git+ssh://git@gitlab.example.com:2222/user/pkg.git"—— 注意开头必须是git+前缀，这是 Composer 唯一认的 SSH 协议标识 - 如果是内部 HTTP 服务且用了自签名证书，还需额外加
"options": { "http": { "ssl": { "verify_peer": false } } }，否则可能卡在后续 HTTPS 请求
{
"repositories": [
{
"type": "vcs",
"url": "git+ssh://git@gitlab.example.com:2222/user/pkg.git"
}
]
}
运行 composer update 前必须清理缓存吗？
不一定，但缓存可能掩盖配置变更。Composer 会缓存仓库元数据（比如 packages.json），如果之前因 URL 错误失败过，缓存里可能存了空或损坏的记录。
- 执行
composer clear-cache是最稳妥的前置动作，尤其当你改完composer.json后仍报同样错误 - 不要只依赖
composer update --no-cache，它跳过远程包缓存，但本地仓库元数据缓存（vendor/composer/installed.json相关）仍可能干扰解析 - 检查当前生效的配置：运行
composer config --list看是否意外启用了全局repositories，它们会和项目级配置合并，优先级容易混淆
私有仓库没配好，会不会连公共包都装不上？
会。Composer 解析 composer.json 时，会对所有 "repositories" 条目做预校验，哪怕你只打算 require 一个 packagist.org 上的包。
- 只要
"repositories"里有一项 URL 格式非法，整个命令就会中断，报 “Invalid repository URL”，完全不往下走 - 如果你只是临时加了个测试仓库，建议用
composer create-project或先注释掉再试，别留着半成品配置 - 更隐蔽的情况：某些 IDE 或编辑器自动补全插入了中文引号、不可见 Unicode 字符，复制粘贴后看着正常，实际 JSON 解析失败 —— 用
composer validate能快速定位这类问题
配置仓库 URL 看似简单，但 Composer 的协议白名单、缓存行为、以及多级配置合并逻辑，会让错误表现和根因脱节。最省事的方式是：删掉所有自定义 repositories，确认基础流程通了，再一条条加回来并立刻验证。
