加载：把死代码变成活对象

各家的加载原语

先把牌摊开。「把静态数据变成可调用对象」这件事，各个平台的原语是：

形状完全一样：给它一坨字节，还你一个能调用的东西。不同的只是那坨字节的格式，和还给你的东西叫什么。

所以「怎么加载」不值得写一章。值得写一章的是加载方式带来的三个后果。

它能看见什么

这是选择加载原语时最直接的差别。JS 里有三种做法，我们把同一段「探针」代码分别放进去，看它能摸到什么。

探针会试着摸三样东西：宿主函数里的一个局部变量、全局对象、以及显式传给它的 ctx。下面这个 demo 是真跑的：

看第一行的差别 —— 这是全章最重要的一个观察。

eval：插件长在你的作用域里

function loadPlugin(src) {
  const hostSecret = 'HOST-INTERNAL-42';
  const db = openDatabase();
  eval(src);              // ← 插件能读到 hostSecret，能读到 db，能改它们
}

eval 在当前作用域里执行代码。这意味着插件能看见、能修改宿主函数内部的每一个局部变量。你精心设计的 ctx 完全没意义了 —— 它旁边那些变量它也全都拿得到。

所以真实世界里没有任何插件系统用 eval 加载插件。它唯一的合法用途是开发者工具里的「执行这段代码」。

new Function：只有全局 + 你显式传的参数

const factory = new Function('module', 'exports', src);
//                            ↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑↑
//                            插件能看见的，只有这些参数 + 全局作用域

new Function 编译出的函数，作用域链的父节点是全局作用域，不是创建它的地方。宿主的局部变量对它完全不存在。

这是所有 JS 插件系统实际在用的那一族（Node 的 vm.Script、浏览器的 import() 本质都在这一侧）。它是「作用域隔离」的正确答案。

模块包装：new Function + 一个受控的壳

就是第 6 章那台宿主用的做法：

const factory = new Function('module', 'exports', src);
const mod = { exports: {} };
factory(mod, mod.exports);
// 插件的产出，现在是 mod.exports 这个对象

这一层壳带来两个好处：插件的代码变成了「执行后留下一个对象」（第 6 章讲过为什么这很关键），以及你控制着传进去的每一个东西 —— 想加个 require 就加，想不给就不给。

Node 的 require 本质上就是这么干的，它包的壳更大一点：

// Node 内部大致是这样（简化）
(function (exports, require, module, __filename, __dirname) {
  // ← 你的模块代码被塞在这里
});

你每天写的每一个 Node 模块，都在一个这样的函数里。那些「凭空出现」的 require、module、__dirname，就是这么被塞进来的 —— 它们不是全局变量，是参数。

加载进来的东西，是「谁」

这个后果在 JS 里很轻，在 JVM 里能要人命。

先说 JS 侧的轻量版。同一个模块被加载两次，会发生什么？

const a = new Function('module','exports', src); const modA = {exports:{}}; a(modA, modA.exports);
const b = new Function('module','exports', src); const modB = {exports:{}}; b(modB, modB.exports);

modA.exports === modB.exports          // false —— 两个不同的对象
modA.exports.SomeClass === modB.exports.SomeClass  // false —— 两个不同的类！

const x = new modA.exports.SomeClass();
x instanceof modB.exports.SomeClass    // false ← 就是这里出问题

同样的源码，加载两次，产出的是两套互不相认的东西。如果插件 A 和插件 B 各自打包了同一个库，然后互相传对象，instanceof 就会给出反直觉的答案。

Node 用「模块缓存」缓解了这个问题（同一个路径只加载一次），但一旦涉及不同版本、不同 node_modules 层级，同样的问题照样出现 —— 这就是 npm 生态里那些「你安装了两份 React」的经典事故。

而在 JVM 上，这个问题被抬到了语言规则的高度：

java.lang.ClassCastException: com.example.Foo cannot be cast to com.example.Foo

它能不能被赶走

这是三个后果里最麻烦的一个。加载是一个动作，卸载不是一个动作 —— 它是一个需要全程配合才能达成的状态。

为什么？因为「加载」这个动作本身会留下痕迹，而且痕迹不在你手上：

// 插件的 activate 里干了这些事
ctx.ui.addCommand('x', '…', fn);        // ← fn 现在躺在宿主的 commands 数组里
ctx.events.on('note:open', handler);     // ← handler 躺在宿主的监听器表里
setInterval(tick, 1000);                 // ← tick 躺在事件循环里
document.addEventListener('click', h);   // ← h 躺在 DOM 上
window.myGlobalCache = new Map();        // ← 挂在全局上了

现在你想卸载这个插件。把 mod.exports 设成 null 有用吗？

完全没用。上面那五个位置每一个都持有一个指向插件闭包的引用，而每个闭包都引用着整个插件模块。只要有一处没清掉，整个插件（连同它加载的所有数据）就永远留在内存里，而且它的定时器还在跑、监听器还在响应。

这就是为什么第 4 章那个注册表的 contribute 一定要返回一个可弃置对象 —— 它把「卸载」从「遍历所有可能的角落去找残留」（一定会漏）变成了「把当初拿到的凭证挨个 dispose」（不可能漏）。

第 13 章会让你亲眼看到没做这件事的下场：来回启停 5 轮之后，宿主上残留 5 个监听器，而它们属于早就「停用」了的插件。

一个常被忽略的选择：要不要支持「热重载」

插件作者最痛的开发体验是：改一行代码，要重启整个应用才能看到效果。

热重载（卸载旧的，加载新的）能极大提升插件开发体验，但它的代价是把「卸载必须干净」从「最好做到」升级成「必须做到」 —— 而且是在开发期反复做，任何一点残留都会累积成诡异的行为（「我明明改了，怎么还是老逻辑」「怎么触发了两次」）。

务实的建议：如果你的插件系统面向的是活跃的第三方开发者，热重载值得做，它对生态的价值超过大多数功能。如果插件主要由你自己写，别做 —— 重启一次的成本远低于把卸载做到完美。

装到自己身上

// ① 最简单：URLClassLoader 加载一个 jar
val loader = URLClassLoader(arrayOf(jar.toURI().toURL()), javaClass.classLoader)
val plugin = Class.forName(mainClass, false, loader)
    .getDeclaredConstructor().newInstance() as NotePlugin

// ② 想卸载？必须让整个 ClassLoader 变成垃圾
//    —— 类是由加载器持有的，只要加载器还活着，类就回收不掉
var loaderRef: URLClassLoader? = loader
plugin.deactivate()
loaderRef?.close()          // 关掉它打开的 jar 文件句柄（Windows 上不关就删不掉文件）
loaderRef = null            // 断掉引用，等 GC
// ⚠ 只要还有任何一个地方持有 plugin 对象、或它的任何一个类，整个加载器都回收不了

// ③ Android：加载一个外部 DEX/APK
val loader = DexClassLoader(
    apkPath,                        // 要加载的 apk/dex
    context.codeCacheDir.path,      // 优化后的 dex 放哪
    null,                           // native 库路径
    context.classLoader             // 父加载器
)

val prev = Thread.currentThread().contextClassLoader
try {
    Thread.currentThread().contextClassLoader = pluginLoader
    // …… 调那个库
} finally {
    Thread.currentThread().contextClassLoader = prev
}

这一章的一句话

加载本身只是一个「给字节还对象」的调用，各平台都很简单；真正要设计的是它的三个后果 —— 它能看见什么（作用域）、它是谁（身份）、它能不能被赶走（卸载）。

下一章我们把「身份」这个后果推到底 —— 那句「Foo cannot be cast to Foo」到底是怎么冒出来的，以及为什么最聪明的插件系统明知有这个坑还是要往里跳。