`final`

final 属性是 structural 属性的反面。它配置了 wasm-bindgen 如何生成 JS 导入以调用导入的函数。值得注意的是，通过 final 导入的函数在导入后永远不会改变，而默认导入（或使用 structural）的函数会受到运行时查找规则的约束，例如遍历对象的原型链。请注意，final 不适合访问 JS 对象的数据描述符属性；要实现这一点，请使用 structural 属性。

final 属性旨在纯粹与性能相关。理想情况下，它不会对用户产生任何可见的影响，并且 structural 导入（默认值）最终应该能够透明地切换到 final。

最终的性能方面是，使用组件模型提案，wasm-bindgen 将需要生成的 JS 函数垫片比现在少得多。例如，考虑今天这个导入

#![allow(unused)]
fn main() {
#[wasm_bindgen]
extern "C" {
    type Foo;
    #[wasm_bindgen(method)]
    fn bar(this: &Foo, argument: &str) -> JsValue;
}
}

没有 final 属性，生成的 JS 看起来像这样

// without `final`
export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return addHeapObject(getObject(arg0).bar(varg1));
}

我们可以看到这里需要这个 JS 函数垫片，但它都是相对独立的。但是，它确实以鸭子类型的方式执行了 bar 方法，因为它从不验证 getObject(arg0) 是否为 Foo 类型来实际调用 Foo.prototype.bar 方法。

但是，如果我们改为写成这样

#![allow(unused)]
fn main() {
#[wasm_bindgen]
extern "C" {
    type Foo;
    #[wasm_bindgen(method, final)] // note the change here
    fn bar(this: &Foo, argument: &str) -> JsValue;
}
}

它会生成这个 JS 粘合代码（大致）

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return addHeapObject(__wbg_bar_target.call(getObject(arg0), varg1));
}

这里的区别很微妙，但我们可以看到被调用的函数是如何从生成的垫片中提升出来，并且始终绑定到 Foo.prototype.bar。然后它使用 Function.call 方法来调用该函数，并将 getObject(arg0) 作为接收者。

但是等等，即使使用 final，这里仍然有一个 JS 函数垫片！没错，这仅仅是未来 WebAssembly 提案尚未实现的事实。但是，语义与未来的组件模型提案相匹配，因为被调用的方法只确定一次，并且它位于原型链上，而不是在函数被调用时在运行时解析。

与未来提案的交互

如果您好奇我们的 JS 函数垫片将如何完全消除，让我们看一下生成的绑定。我们从这个开始

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return addHeapObject(__wbg_bar_target.call(getObject(arg0), varg1));
}

... 并且一旦引用类型提案实现，我们就不需要一些烦人的函数。这将使我们生成的 JS 函数垫片看起来像这样

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, arg1, arg2) {
    let varg1 = getStringFromWasm(arg1, arg2);
    return __wbg_bar_target.call(arg0, varg1);
}

越来越好了！接下来我们需要组件模型提案。请注意，该提案目前正在进行一些更改，因此很难链接到参考文档，但足以说明它将至少为我们提供两种不同的功能。

首先，组件模型承诺提供“参数转换”的概念。这里的 arg1 和 arg2 值实际上是指向 utf-8 编码字符串的指针和长度，使用组件模型，我们将能够注释该导入应该接受这两个参数并将它们转换为 JS 字符串（即，主机应该这样做，WebAssembly 引擎）。使用该功能，我们可以进一步将其缩减为

const __wbg_bar_target = Foo.prototype.bar;

export function __wbg_bar_a81456386e6b526f(arg0, varg1) {
    return __wbg_bar_target.call(arg0, varg1);
}

最后，组件模型提案的第二个承诺是，我们可以标记一个函数调用来指示第一个参数是函数调用的 this 绑定。今天，所有被调用导入函数的 this 值都是 undefined，而这个标志（使用组件模型配置）将指示这里第一个参数实际上是 this。

考虑到这一点，我们可以进一步将其转换为

export const __wbg_bar_a81456386e6b526f = Foo.prototype.bar;

瞧！我们使用引用类型和组件模型，现在根本不需要任何 JS 函数垫片来调用导入的函数。此外，未来对 ES 模块系统的 wasm 提案也可能意味着我们甚至不需要这里的 export const ...。

还值得指出的是，在所有这些 wasm 提案实现后，导入 bar 函数的默认方式（即 structural）将生成一个看起来像这样的 JS 函数垫片

export function __wbg_bar_a81456386e6b526f(varg1) {
    return this.bar(varg1);
}

其中这个导入仍然受到运行时原型链查找等的约束。

`wasm-bindgen` 指南

final

与未来提案的交互

`final`