JS 派：三种把代码放进来的姿势

姿势一：直接 require（Obsidian）

最简单的一种。Obsidian 是 Electron 应用，插件的 main.js 被直接在渲染进程里加载：

// 宿主那侧（示意，Obsidian 内部细节未公开，但机制就是这个）
const pluginModule = require(`${vaultPath}/.obsidian/plugins/${id}/main.js`);
const PluginClass = pluginModule.default ?? pluginModule;
const instance = new PluginClass(app, manifest);
await instance.onload();

插件和宿主共享一切：同一个 V8 隔离区、同一个全局对象、同一个事件循环、同一份 Node 集成能力。

这意味着插件能做的事，和 Obsidian 自己能做的事完全相同：

// 插件里这些全都可以，没有任何东西拦着
require('fs').readFileSync('/etc/passwd');
require('child_process').execSync('任何命令');
document.body.innerHTML = '';                 // 想清空整个界面也行
app.vault.adapter                             // 宿主的内部对象，随便拿
Object.prototype.toString = () => '哈';        // 甚至可以污染原型链

这是一个自洽的选择（第 2 章讲过），但要清楚它把安全责任整个转移给了用户和审核流程。

姿势二：独立进程（VS Code）

VS Code 把插件请出了 UI 进程。它的进程结构大致是：

# VS Code 的进程们
主进程（Electron main）
 ├─ 渲染进程（窗口 / UI / 编辑器）  ← DOM 在这里
 ├─ extension host（Node 进程）     ← 插件全部在这里，没有 DOM
 ├─ 语言服务器们（插件自己拉起的子进程）
 └─ 其它辅助进程（搜索、文件监视…）

插件的加载就是在 extension host 那个 Node 进程里 require。加载动作本身和 Obsidian 一样简单，差别在于它发生在哪个进程里。

而一旦跨了进程，所有交互都必须变成消息：

// 插件写的是这样（看起来像普通调用）
const doc = await vscode.workspace.openTextDocument(uri);
await vscode.window.showTextDocument(doc);

// 底层实际发生的（简化）
// extension host → 序列化成 {rpcId, method:'openTextDocument', args:[...]}
//               → IPC 管道
//               → 渲染进程反序列化，真的去打开文档
//               → 结果序列化回来
//               → Promise resolve

VS Code 在 extension host 启动时会为每个 UI 服务建立代理对象：你调一个方法，它把调用序列化成消息发过去，等回复。

代价：几乎所有 API 变成异步（第 18 章会让你亲手体验），以及跨进程传数据要序列化（大对象会有开销，DOM 那种带循环引用的活对象树根本传不过去 —— 这也是「不给 DOM」的技术原因之一，不只是政策）。

姿势三：独立世界（Chrome）

Chrome 的做法最特别，因为它面对一个前两家都没有的难题：插件代码必须和一个完全不可信的网页共处一室。

content script 需要读写页面的 DOM（这是它存在的意义），但又不能和页面的 JS 混在一起。Chrome 的解法叫独立世界：

// 页面自己的脚本
window.secret = '页面的数据';
window.jQuery = jQuery_v1;
Array.prototype.map = function () { return '我劫持了 map'; };   // 页面在搞破坏

// 你的 content script —— 同一个页面，不同的世界
console.log(window.secret);        // undefined  ← 看不见页面的变量
window.jQuery = jQuery_v3;         // 不影响页面的 jQuery
[1,2].map(x => x);                 // 正常  ← 页面污染的原型链影响不到你
document.querySelector('h1');      // 正常  ← 但 DOM 是共享的

切得极其精准：DOM 共享，JS 变量空间隔离。

为什么这一刀是对的？因为：

• 扩展要干的活（改页面内容）全都需要 DOM；
• 扩展和页面互相搞坏对方的常见方式（覆盖全局变量、污染原型链、抢同名函数）全都发生在 JS 变量空间。

顺带还解决了「多个扩展在同一个页面上互不干扰」—— 各在各的世界里。

而真正有权力的那部分代码（能调 chrome.tabs、chrome.cookies 的），被放在另一个地方：service worker。content script 只能通过消息请它办事：

// content.js —— 能碰 DOM，但没什么权力
chrome.runtime.sendMessage({ type: 'fetch', url }, (resp) => {
  document.querySelector('#box').textContent = resp.data;
});

// sw.js —— 有权力，但碰不到页面 DOM
chrome.runtime.onMessage.addListener((msg, sender, sendResponse) => {
  if (msg.type === 'fetch') {
    fetch(msg.url).then(r => r.text()).then(data => sendResponse({ data }));
    return true;   // 表示会异步回复
  }
});

三种姿势并排

最后一行解释了一切。Chrome 的方案需要在 V8 里实现「同一个 document 挂多个 JS 上下文」—— 那是浏览器厂商才做得到的事。VS Code 的方案需要几万行 RPC 基础设施。Obsidian 的方案需要一行 require。

所以这不是「谁更用心」的问题，是谁有多少预算、面对多大风险的问题。

还有第四种：换一个 JS 运行时

上面三种之外，还有一类做法：不用宿主的 JS 引擎，而是嵌一个独立的。

WASM 那一行值得多说一句，因为它的默认状态和其它所有方案都相反：一个 WASM 模块天生什么都做不了 —— 没有文件、没有网络、没有系统调用，甚至没有时钟。它能做的每一件事，都必须由宿主显式地作为导入函数交给它。

这正是插件系统梦寐以求的默认值：不是「拿走它不该有的」，而是「只给它该有的」。代价是数据传递麻烦（只能传数字，字符串和对象要自己在线性内存里编解码）和生态还年轻。但如果你今天从零设计一个需要强隔离的插件系统，WASM 是最该认真评估的选项。

const vm = require('vm');
// 看起来什么都没给它
const result = vm.runInNewContext(`
  this.constructor.constructor('return process')().mainModule.require('fs')
`);
// 拿到了 fs 模块 —— 逃逸成功

装到自己身上

// 第一版：同进程，但 API 就写成 async
const api = {
  async readNote(id) { return host.find(id)?.body ?? null; },
  async writeNote(id, text) { /* … */ },
};

// 半年后要上 Worker 隔离 —— 插件代码一个字都不用改
const api = {
  async readNote(id) { return rpc('readNote', id); },
  async writeNote(id, text) { return rpc('writeNote', id, text); },
};

这一章的一句话

同样是 JavaScript，三家的隔离强度差了两个数量级 —— 差别不在技术能力，在于每一家愿意为隔离付多少钱；而不管你现在选哪种，把 API 设计成异步，就是给未来的自己留了一扇门。

下一章处理加载的第三个后果，也是最难的那个：怎么让一个已经进来的插件，干净地消失。你会亲眼看到「没做干净」长什么样。