3.4 实例化与链接模型

3.4 实例化与链接模型

本节摘要：实例化是把静态字节点亮成运行态的通电仪式：分配状态、接通导入、铺初始数据、执行启动函数。链接则是对账仪式——模块申报的需求与宿主递交的供给必须逐项签名吻合。本节把两个仪式的每一步摊开，并示范多模块拼装的工程写法。

别以为验证通过就算万事大吉——模块被拒收只在加载瞬间疼一下，而实例化与链接阶段的问题全部藏在运行边缘：少递了导入、签名对不上、数据段越界，任何一样都会让模块在千钧一发处熄火。理解这两个仪式，等于拿到了"模块为什么起不来"这类问题的诊断手册。

实例化的六步仪式

一个模块从字节到可调用，引擎按固定顺序走六步。顺序本身有讲究，前一步的产物是后一步的原料。

第一步，核验字节：确认模块已通过验证（多数引擎把验证与编译合并执行，浏览器里流式编译边下边验）。第二步，创建实例骨架：为该实例的内存、表、全局变量分配独立副本——同一模块实例化多次，彼此的状态互不可见。第三步，接通导入：按导入节逐项从宿主递入的导入对象里取货，函数核对签名、内存核对容量下限、全局核对类型与可变性，任何一项缺失或不符，实例化即刻失败。第四步，铺初始数据：数据节把字节段写进线性内存的指定偏移，元素节把函数引用装进表——写不下的（比如数据段终点超出内存申报容量）同样当场失败。第五步，执行起始函数：若模块声明了 start，此时运行一次，做模块级的自检与初始化。第六步，交付导出：把导出表交给宿主，从此可以调用。

const importObject = {
  env: {
    // 模块申报 (import "env" "log" (func (param i32))) —— 签名必须严格一致
    log: (value) => console.log("wasm says:", value),
    // 模块申报 (import "env" "mem" (memory 1)) —— 容量不得小于申报下限
    mem: new WebAssembly.Memory({ initial: 2 }),
  },
};
const { instance } = await WebAssembly.instantiateStreaming(
  fetch("app.wasm"), importObject
);
instance.exports.run();
​

第三步是绝大多数事故现场。报错信息通常直白："导入缺失 env.log"或"内存导入容量不足"，但排查思路值得固化：从报错里的命名空间与名字出发，回模块的导入节清单逐项核对——名字对不上（大小写、拼写）、签名对不上（参数个数或类型）、类别对不上（要函数给了数值），是三类高频原因。

图 3-C：实例化流水线——从字节到可调用

链接：模块之间的报关对账

链接不止发生在模块与宿主之间，也发生在模块与模块之间。Wasm 的链接是纯显式的：A 模块要调用 B 模块的函数，就在自己的导入节里申报，实例化时把 B 的导出递进 A 的导入对象——依赖关系全部写在纸面上，没有任何隐式解析。这与传统动态链接（按符号名全局搜索）是两种哲学：Wasm 把"谁依赖谁"变成可审计的申报单，代价是没有递入就没有运行。

多模块拼装的 JavaScript 写法并不复杂，关键是顺序：

// 先实例化被依赖的库模块
const lib = (await WebAssembly.instantiateStreaming(fetch("libmath.wasm")))
  .instance;

// 把库模块的导出作为依赖方的导入递入
const app = (await WebAssembly.instantiateStreaming(
  fetch("app.wasm"),
  { lib: lib.exports }         // app 申报过 (import "lib" "...") 系列
)).instance;

app.exports.main();
​

服务端运行时把这个模式包装得更顺：第六章的组件模型将把"按接口申报与授予"升级成正式标准，跨语言拼箱不再需要手写这层 JavaScript 胶水。此处只需记住结论——依赖注入在 Wasm 里是字面意义的运行时机制：导入节是构造函数参数，实例化是依赖注入容器的一次 resolve。

起始函数与对账报错的实战细节

起始函数（start）有两点部署期纪律。其一，它运行在"数据已铺好、导入已接通"的时点，适合做自检——校验内存里的魔数、初始化内部状态——但不适合做重活：宿主往往在实例化阶段有严格时限，起始函数超时会拖垮整条加载路径。其二，起始函数里的陷阱会把整个实例化判为失败，报错混在链接错误里出现，排查时先分清"导入没接上"与"起始函数自己摔了"这两类原因。

不少工程团队干脆禁用起始函数，把初始化改成一个显式的导出函数（比如 init），由宿主在实例化完成后按需调用。代价是宿主要多记得调一次，收益是初始化的时机、超时与错误处理全部收归宿主编排——在插件系统这类多租户场景里，这笔交易通常很划算。

对账报错的读法也有章可循。链接错误的信息通常带三层坐标——命名空间、名字、期望签名——逐层核对即可：命名空间不符是导入对象的顶层键写错；名字不符是二级键的拼写或大小写；签名不符则要看参数个数、类型与返回值是否与申报一致。把这三层坐标印在脑海里，浏览器控制台或运行时日志里那行冗长的报错就变成了填空题。多模块拼装时还有一招防身术：先用静态查询列出被依赖模块的全部导出，再对照依赖模块的导入清单逐项打钩，实例化前就把对账做完——运行时报错永远比预检报错贵。

本节要点回顾

• 六步仪式顺序固定：核验、建骨架、接导入、铺数据、跑起始、交导出，失败在哪一步报错就在哪一类；
• 三类失败分头排查：验证错误看偏移、链接错误看命名空间与签名、陷阱看原因与调用链；
• 导入对账是逐项签名核对：名字、类别、签名、容量下限缺一不可，差异即拒装；
• 多模块链接全显式：被依赖者先实例化，其导出作为依赖者的导入递入；
• 实例是状态的独立副本：一模一样，多份点亮，互不可见——插件与多租户隔离的物理基础。

至此内核章节收官：栈怎么推、控制流怎么走、内存怎么碰、实例怎么点亮，全部打通。下一章回到岸上，看把高级语言装进箱子的工具链。