Composer没有BaseRepository抽象基类，所有仓库类型均直接实现RepositoryInterface；ComposerRepository处理HTTP元数据，VcsRepository管理版本控制，PathRepository扫描本地目录；自定义仓库必须直接实现接口，不可继承不存在的基类。
Composer 没有 Base-Repository 抽象基类，所谓“Base-Repository 继承体系”是误解——所有仓库类型（composer、vcs、package、path）都直接实现 RepositoryInterface，不共享统一父类。
为什么找不到 BaseRepository 类
Composer 源码中不存在名为 BaseRepository 或类似名称的抽象类。你搜不到它，不是因为路径深或命名隐晦，而是根本没这东西。官方仓库驱动（如 Composer\Repository\ComposerRepository、Composer\Repository\VcsRepository）彼此独立，各自实现 RepositoryInterface，没有公共继承链。
-
ComposerRepository专用于处理packages.json和provider-*.json的 HTTP 元数据解析 -
VcsRepository负责 Git/SVN 等版本控制系统拉取、检出、缓存，完全绕过 JSON 元数据层 -
PathRepository不发起任何网络请求，只扫描本地目录结构并构建包列表 - 所有类都直接 implements
RepositoryInterface，方法签名一致（findPackage()、getPackages()等），但内部逻辑无复用设计
自定义仓库时别试图 extends BaseRepository
如果你在写私有仓库插件，想复用“通用仓库逻辑”，会发现无处可 extend。Composer 不提供可继承的基类，也不鼓励继承式扩展——它靠的是接口契约 + 插件注册机制。
围绕关键发现、作用机制、临床相关性及研究局限性展开讨论。适用于撰写或优化任何生物医学论文的“讨论（Discussion）”部分——包括结果解读、与既往文献关联、阐释意外发现、界定研究局限性，以及撰写结论。当用户输入以下任一指令时也会自动触发该功能： - “write my discussion” - “help me discuss my findings” - “how do I compare to prior studies” - “write the limitations par
- 插件中调用
RepositoryManager::addRepositoryClass('my-type', MyCustomRepo::class)时，MyCustomRepo必须直接实现RepositoryInterface - 不能写
class MyCustomRepo extends BaseRepository—— PHP 会报Class 'BaseRepository' not found - 想复用逻辑？只能手动 copy-paste
ComposerRepository中的 HTTP 工具方法（如$this->getDownloader()->download()），或封装成独立工具类 - 注意：
ComposerRepository内部强依赖HttpDownloader和PackageDiscovery，这些不是公开 API，版本升级可能破坏兼容性
RepositoryInterface 各方法的真实行为差异极大
接口统一，但实现天差地别。同一方法名在不同仓库里语义完全不同，误判会导致静默失败或性能灾难。
-
findPackage('foo/bar', '^1.0')在ComposerRepository中触发 HTTP 请求 + JSON 解析；在PathRepository中只是文件系统遍历 +composer.json读取 -
getPackages()对VcsRepository来说可能返回空数组（默认不预加载），而ComposerRepository会尝试加载全量packages.json（除非启用 provider 模式） -
hasPackage()在PackageRepository（静态包定义）中是 O(1) 数组 key 查找；在VcsRepository中需先 fetch 远程 tag 列表，实际是网络 I/O - 调用
findPackage()前，务必确认当前仓库类型是否支持该查询粒度——比如PathRepository不支持版本约束语法，只认精确 name+version 字符串匹配
真正容易被忽略的点是：Composer 从不校验你传入的仓库类是否“合理实现”了接口。它只检查是否 implements RepositoryInterface，然后无条件调用方法。一旦你的 findPackage() 返回 null 或格式错误的 PackageInterface 实例，后续依赖解析就会在深不可测的位置崩掉，且日志里只显示 Could not find package，不会告诉你哪一行实现错了。
