应使用vcs类型当需从Git/SVN等仓库动态解析分支和tag并自动识别版本时，url须为可git clone地址且包名必须与仓库composer.json的name字段完全一致。
Composer 自定义仓库只有三种合法 type：`vcs`、`path`、`composer`，其中 `package` 是伪类型（仅用于手动声明单个包），不能算独立仓库方式。用错类型或混用逻辑，composer require 就会静默失败或拉错版本。
什么时候该用 vcs 类型？
当你需要从 Git/SVN/Mercurial 仓库动态解析分支和 tag，并让 Composer 自动识别版本时，必须用 vcs。它不索引整个仓库，只在运行时按需 clone 并读取目标引用（如 dev-main、v1.2.3）对应 commit 的 composer.json。
-
url必须是可直接git clone的地址，例如https://gitlab.example.com/org/sdk.git；带/releases/tag/或缺.git后缀都会失败 - 仓库根目录的
composer.json中name字段必须与require里的包名完全一致（如"name": "org/sdk"，不能是"sdk"） - 版本字符串必须严格匹配真实 Git 引用：
v1.2.3要求存在 tag 名为v1.2.3，且其composer.json中"version": "1.2.3"（不能带v前缀） - 认证走
auth.json或全局composer config -g，绝不能把 token 拼在 URL 里（https://token:x-oauth-basic@...已被 Composer 1.10+ 弃用）
什么时候该用 path 类型？
当你在本地开发一个包，想实时测试它被其他项目引用的效果，path 是唯一低开销方案。它跳过网络、不 clone、不解析 tag，直接 symlink 或 copy 文件。
-
url是相对或绝对路径，基于主项目composer.json所在目录解析，不支持~或环境变量 - 路径末尾加不加
/不影响，但推荐统一加，避免歧义 - 支持 glob：如
"../packages/*"会扫描所有子目录，只要含合法composer.json就纳入候选 - 启用
"options": {"symlink": true}可让vendor/下生成软链接，改源码立刻生效；但 CI 环境通常禁用 symlink，得靠composer install --no-dev配合清理
vcs 和 path 的关键差异在哪？
核心区别不在“能不能用”，而在“谁控制版本生命周期”：vcs 把版本决策交给 Git 本身（tag/branch），path 完全由本地文件系统状态决定，没有版本概念——* 就是当前目录内容，dev-main 这种写法在 path 下无效。
-
vcs依赖网络 + 权限 + Git 服务稳定性；path依赖路径存在性 + 读写权限，CI 中若路径不存在会直接报错 -
vcs支持composer update拉新 tag；path下update只刷新 symlink 或 copy，不会自动 git pull - 同一包名同时出现在
vcs和path仓库中时，path优先级更高（Composer 按repositories数组顺序匹配，先命中即止） -
path无法用于发布环境，上线前必须删掉或注释掉对应配置，否则会把开发机路径打进生产 vendor
最容易被忽略的是：无论用哪种方式，repositories 只是“告诉 Composer 去哪找”，真正起作用的是 require 里的包名是否能被某个仓库的 name 字段精确匹配——漏配、拼错、大小写不一致，都会导致 Composer 回退到 packagist.org 并报 404。
