合法type值仅限大小写敏感的"composer"、"vcs"、"package"、"path"四种，多空格、少字母或拼写错误（如"git"）均导致直接报错；还需排除JSON解析异常、URL协议不匹配及全局配置冲突。
“Unrecognized repository type” 错误只发生在 repositories 配置中 type 字段值非法时，不是拼写错误就是用了 Composer 不支持的类型——它不会尝试 fallback，直接报错退出。
哪些 type 值是合法的
Composer 只认这几个硬编码的字符串，大小写敏感，多一个空格、少一个字母都不行：
-
"composer"：指向 Packagist 兼容的元数据服务（如 Satis、Private Packagist） -
"vcs"：Git / SVN / Mercurial 等版本控制系统仓库 -
"package"：手动内联定义单个包（含name、version、dist等字段） -
"path"：本地文件系统路径（如"../my-package"）
常见错误包括："git"（应为 "vcs"）、"github"（不存在该类型）、"private"（无意义）、"composer-v2"（Composer 不识别带版本号的 type）。
type: "vcs" 却报 unrecognized？检查 URL 是否触发了隐式类型推断失败
当 type 显式设为 "vcs"，但 url 字段值让 Composer 无法判断底层协议时，它会放弃解析并退回到“unrecognized”错误（而非更具体的克隆失败）。典型情况有：
-
url是浏览器地址，如"https://github.com/user/repo"（缺.git后缀） -
url是 SSH 地址但格式不标准，如"git@gitlab.example.com:user/pkg"（缺git+ssh://前缀或端口） -
url使用了非白名单协议，如"ftp://"或自定义 scheme"myproto://"
验证方式：在终端运行 git ls-remote -h {your-url}。如果这条命令失败，Composer 几乎肯定会在仓库校验阶段卡住并报 unrecognized。
嵌套配置或注释导致 JSON 解析失败，间接引发 type 识别异常
Composer 解析 composer.json 是严格按 JSON 规范来的。以下写法看似无害，实则会让整个 repositories 数组失效：
- 在
repositories数组里加了 JavaScript 风格注释//或/* */ - 末尾多了一个逗号：
"type": "vcs",后紧跟]（某些 PHP JSON 扩展不兼容尾随逗号） - 用单引号代替双引号包裹 key 或 string 值
-
repositories被意外写在了extra或config下层，而非根级字段
最简验证法：php -r "json_decode(file_get_contents('composer.json'), true) or die('JSON error: '.json_last_error_msg());"。只要这行报错，type 就根本没被读到。
全局配置和项目配置合并后 type 冲突
Composer 会把全局 ~/.composer/config.json 和项目级 composer.json 的 repositories 合并。如果其中某条记录的 type 是非法值，哪怕只有一条，整个合并后的数组都会被拒绝。
排查步骤：
- 运行
composer config --list | grep repositories查看实际生效的完整仓库列表 - 逐条检查输出中的
repositories.*.type字段值 - 若发现可疑项，用
composer config --global --unset repositories.xxx清理（xxx 是对应索引或名称）
真正容易被忽略的是：你改了项目 composer.json，但忘了删掉全局配置里一条早已废弃的 "type": "toran" 记录——它就足以让所有后续操作失败。
