ARTICLE · 1214257
插件志 · 模块综述(二):架构与契约
专栏「插件志」· 署名：榫卯手
本篇是「插件志」五模块合集的第二辑，把架构与契约这条主线上的五篇——《扩展点设计》《清单驱动》《发现与装配》《激活与运行时》《隔离模型》——收成一份摘要式综述。
一、本模块在讲什么
架构与契约，是插件系统的骨架。 它回答一个核心问题：宿主如何在不被反噬的前提下，把能力开放出去？五篇恰好串成一条主线——
声明（清单）→ 扩展（扩展点）→ 装配（发现解析）→ 激活（运行时）→ 隔离（信任边界）
从"插件递上一张纸"，到"宿主把它接上、关进笼子"，这是插件系统区别于"直接 import 一个库"的全部奥妙。
二、逐篇摘要与引用
05 · 扩展点设计：为什么有的插件系统优雅，有的变成 plug-in hell
插件系统的优雅或崩坏，往往不取决于代码，而取决于"扩展点"该用哪种拓扑、多粗多细、如何版本化。
- •
四拓扑坐标系：宿主-扩展、管道-过滤器、协议、适配器——同一词，四种根本不同的回答。
- •
粒度光谱 + 版本化命门：扩展点定错，就从"优雅可扩展"滑向 plug-in hell。
- •
06 · 清单驱动：让宿主不运行你的代码，也能读懂你
插件系统最反直觉的一点：宿主在你代码运行之前，就已经靠一张"清单"读懂了你。
- •
声明与执行分离：manifest 同时是身份证、能力表、约束书——安全、性能、治理共同的基石。
- •
四家横评：Chrome、VS Code、IntelliJ、Figma 的 manifest 对照。
- •
07 · 发现、依赖解析与装配：插件生态的交通枢纽
清单被宿主读懂之后，下一步是把散落各处的插件"装配"成系统。
- •
立交桥四步：发现（Discovery）→ 解析（Resolution）→ 注册（Registration）→ 装配（Assembly）。
- •
冲突解决：DAG、semver、四家策略对比——这一层不出彩，却决定丝滑还是崩盘。
- •
08 · 激活与运行时：插件从"装进去"到"跑起来"的最后一公里
装配完 ≠ 跑起来。激活策略与通信机制，决定了一个插件系统是秒开还是卡死。
- •
四种激活：从用户显式触发到声明即永驻（VS Code / Chrome SW / Figma / Koishi）。
- •
通信与隔离：直接 API、RPC、事件总线、声明式贡献；异步优先、不阻塞主线程。
- •
09 · 隔离模型：插件能搞坏什么，由信任边界说了算
插件装进去、跑起来之后，最危险的问题是"它能搞坏什么"。
- •
信任边界：五档隔离——同进程无隔离 → OSGi 类加载器 → 独立进程 → iframe 沙箱 → Wasm 语言级。
- •
四维隔离 + 纵深防御：故障 / 数据 / 能力 / 性能，成本与收益逐档权衡。
- •
三、模块综合洞察
- 1.
契约先于代码：清单（声明）是安全、性能、治理的总闸门，比任何运行时技巧都靠前。
- 2.
扩展点是旋钮：拓扑、粒度、版本化三件事，决定系统是优雅还是 hell。
- 3.
装配是隐形的命门：发现与依赖解析做不好，前面再漂亮也崩在最后一公里。
- 4.
隔离是最后一道闸门：信任边界决定"插件能跑多远、能碰什么"，把不确定性关进笼子。
