ARTICLE · 1196523
发现、依赖解析与装配:插件生态的交通枢纽
清单被读完之后，宿主如何把"散落各处的插件"变成"可被调用的能力"？
核心命题：上一篇《清单驱动》里，宿主在运行你代码之前，已经靠一份 manifest 读懂了你。但"读懂"不等于"装好"——清单只是插件递上的一张名片。宿主接下来要做的是一件更脏更累的活：找到那些散落在文件系统、网络 registry、甚至别人电脑上的插件，解析它们之间纠缠的依赖，注册进自己的运行时，最后物化成可被调用的能力。这一层，就是插件生态的"交通枢纽"。它不出彩，却决定了一个生态是丝滑扩展，还是 step 崩盘。
引子：从"读懂"到"装好"之间，隔着一座立交桥
想象你拿到了一张参展商名录（清单）。名录告诉你：A 公司卖芯片、B 公司卖外壳、C 公司卖螺丝。但博览会现场，A 的仓库在地下室、B 的货柜在城东、C 的螺丝散落在三楼走廊。要把它们拼成一个成品，你需要一个物流系统——谁在哪儿、谁依赖谁、谁先到位。
插件系统就是这样一座物流立交桥。它站在 03《核心闭环》的"插件声明"之后、"按需激活"之前，承担着最不起眼却最致命的一环：发现（Discovery）→ 解析（Resolution）→ 注册（Registration）→ 装配（Assembly）。
本篇，我们把这座立交桥拆开，看 WordPress、npm、Eclipse/OSGi、VS Code 四家，怎么把"散落各处的插件"变成"系统里可用的能力"。
发现机制光谱：从文件系统扫描到可插拔发现
一、发现（Discovery）：插件"存在"但"未知"，怎么变"已知"？
发现解决第一个问题：宿主怎么知道有哪些插件可用？ 四种范式，构成一条从"零配置"到"可编程"的光谱。
① 文件系统扫描（最原始）——代表：WordPress。 WordPress 扫描 wp-content/plugins/ 及其一级子目录下的 PHP 文件，读前 8KB 提取"Plugin Header"注释块（Plugin Name 必填，Version/Author/Requires at least 等选填），解析出插件元数据缓存起来（get_plugins()）。还有一类"Must-Use 插件"（mu-plugins/）根本不扫描子目录，且每次请求自动加载、无法在后台停用——这是 WordPress 留给自身的"免发现"应急通道。
② 本地清单聚合（离线优先）——代表：Eclipse、VS Code。 Eclipse 的 configurator 插件从 eclipse/plugins 文件夹、以及 eclipse/links 链接的本地目录、甚至用户自选位置"拾取"插件。VS Code 的 ExtensionsScanner 反过来遍历本地扩展目录、读每个扩展的 package.json 清单。两者的共同点是：不联网也能装配，适合桌面端离线场景。
③ 注册表 / 中心服务（联网查询）——代表：npm registry、VS Code Marketplace。 npm 把全世界的包元数据集中放在 registry；VS Code 通过一个 RESTful 接口（_apis/public/gallery/extensionquery，POST）让客户端按名称、发布者、分类、标签、搜索词查询扩展，还能带回下载量、评分、版本等统计。这是"发现"与"分发"合一的形态——下一站第 15 篇（分发与市场）会深挖。
④ 可插拔发现（可编程）——代表：Eclipse Update Manager。 最灵活的一种：连"怎么发现"本身都是插件。Eclipse 的 configurator 可被替换，新的 configurator 能从远程应用服务器"provision"并配置插件。这把"发现策略"也变成了可扩展点（呼应 05《扩展点设计》）。
小结：发现，本质上是把"存在但未知"的插件，变成"注册表里有条目"的插件。越靠左（扫描），越简单但越脆弱；越靠右（可插拔），越强大但越复杂。
二、解析（Resolution）：依赖图与语义化版本的博弈
插件被发现后，紧接着是更难的一步：它们之间互相依赖，怎么解？ 这一步稍有疏忽，就滑向 Birsan 反复警告的 "plug-in hell"。
依赖图的形状。无论是 npm 还是 OSGi，解析器都把你的项目当作一张有向无环图（DAG）的根，递归访问每条依赖边，收集每个包名被请求的版本范围。关键不在"单包"，而在"多父同求一包"。
语义化版本的交集（npm 范式）。当 A 和 B 都依赖 lodash，解析器取两者范围的交集，选满足所有约束的最高版本——所以 ^4 和 ^4.5 共享一份 4.17。但一旦 A 要 react@^17、B 要 react@^18，交集为空，npm 要么把冲突版本嵌套到需要它的包下面（默认 hoisting + 嵌套回退，自 npm v3 起），要么在 peer dependency 这种"该由消费者提供"的依赖上直接失败（ERESOLVE）。
运行时解析与并发版本（OSGi/Eclipse 范式）。Eclipse 把依赖直接写进插件清单，由运行时 kernel 在启动时解析。麻烦在于同一插件可能在两个位置装了两份、甚至同版异版共存：两者都贡献菜单项时，界面会出现重复条目。Eclipse 的折中约定是——只有"只贡献代码库、不贡献界面/文档"的插件才允许同运行时共存，其余一律取最新版（除非配置文件精确指定）。这解决了"重复菜单"的尴尬，却也让插件在 Eclipse 里没能"一视同仁"。
循环依赖是红线。依赖图必须是 DAG。一旦成环，要么直接拒绝，要么靠某种机制打破（比如允许单向延迟绑定）。这是所有解析器的共同底线。
依赖解析 DAG：范围交集、冲突嵌套与硬失败
三、注册（Registration）：registry 到底是什么？
解析完，插件得"落户"。Birsan 给了一个干净的界定：运行时 kernel 至少要维护两类表——
- •
已装插件注册表（installed plug-ins registry）：记录装了哪些插件、各自提供什么函数；
- •
扩展注册表（extension registry）：记录"谁定义了扩展点、谁往里插了扩展"。当某插件定义了扩展点，它自己负责用这个注册表查找它的 extenders、实例化回调类、调用接口方法。
VS Code 把这套思想落地成 ExtensionManagementService：它维护本地安装元数据与 gallery 元数据的双向引用（Extension 类同时包着本地和远程两份数据），并校验兼容性（目标平台、VS Code engine 版本、启用的 API proposals）。WordPress 则把"已激活插件"直接序列化成数组，存进数据库 wp_options 表的 active_plugins 选项——激活态在 DB，不在文件系统，所以移动主文件会让插件"失活"。
注册表因此有两种形态：内存注册表（运行时飞快查询）与持久注册表（DB/文件，跨重启存活）。
四、装配（Assembly）：把解析结果"物化"到磁盘与内存
最后一步，是把"逻辑上的依赖图"变成"物理上能跑的东西"。四家各有招式：
- •
npm：把解析后的树 reify（物化）进
node_modules，用 hoisting 把兼容版本提到顶层共享、冲突版本嵌套。再加一份package-lock.json锁定版本与完整性 hash，保证"换台机器、CI 里也能装出一模一样的树"。 - •
Eclipse：极小的 bootstrap 代码启动核心插件，初始化插件注册表与扩展模型、解析依赖；其余插件代码此时一律不跑，等到被请求才激活（呼应 03 的"按需激活"）。
- •
VS Code：本地扫描 + gallery 查询 → 下载并解压
.vsix→ 注册元数据 → 交给 Extension Host 加载运行。 - •
WordPress：扫描 → 解析 Plugin Header → 读
active_plugins→ 每次请求早期用include_once()把激活插件文件挨个引入。没有按需激活这一说——这是它简单，也是它重（装得多、启动就慢）。
五、冲突解决策略对比（结论 / 产出 ①）
把四家摆在一张表上，差异一目了然：
最刺眼的一栏是 WordPress：它几乎把"冲突解决"外包给了文件系统（目录结构）和数据库（激活态）。简单到极致，也脆弱到极致——装个插件要挪文件夹、激活态会随路径变化而丢失。这正是"交通枢纽"设计投入不足的典型代价。
六、依赖解析算法对比 + 反模式清单（结论 / 产出 ②）
不同系统的解析算法，本质是"范围语义 + 物化拓扑"的组合拳：
- •
npm：声明范围 → DAG 构建 → semver 交集 → 去重提升 → 锁文件 → 物化（hoisted/nested）。代价是幽灵依赖（phantom dependency，你没声明却能 import 到别人提升上来的包）。
- •
OSGi / Eclipse：能力—需求（capability/requirement）模型，运行时动态解析，支持多版本共存，但配置复杂度陡增。
- •
Maven（顺带一提）：传递依赖 + "最近版本胜出" + 依赖调解。
- •
Eclipse：插件依赖 + 版本范围 + feature 打包（把一组插件当部署单元，缓解"上千个插件让用户挑花眼"的可扩展性问题）。
反模式清单（装配层 7 条）：
- 1.
范围过宽（
*或>=无上限），装出从未测试的版本组合； - 2.
无锁文件，CI 与本地装出不同树（"在我机器上是好的"之源）；
- 3.
环状依赖，解析器直接罢工；
- 4.
幽灵依赖，靠 hoisting 蹭别人的包，换个顺序就崩；
- 5.
重复副本失控，同一库装 N 份，体积与内存双爆；
- 6.
激活顺序敏感，插件 A 必须在 B 之前加载，否则错；
- 7.
把激活态绑死在路径上（WordPress 式），挪一下就失活。
四家冲突解决策略对比 + 装配层反模式清单
七、衔接 08：装配完，就到了"按一下才跑"
装配把插件"装进"了系统，但装了 ≠ 跑了。下一站《激活与运行时》，我们看四家如何"按需激活"——VS Code 的 activationEvents、Eclipse 的懒加载、WordPress 那种"每次请求全量 include"的奢侈与代价。交通枢纽把货送到了站台，下一站是发车时刻表。
