WebAssembly 面试题

本题库共收录 55 道面试题（基础 12 / 进阶 19 / 深入 15 / 架构 9）。本文件收录 WebAssembly 相关面试题，目标题量 60 道。题型覆盖：概念题、代码分析题、手写代码题、场景设计题、系统设计题、框架原理题、性能优化题、安全题、工程化题、综合开放题。难度覆盖：基础、进阶、深入、架构。每道题除标准参考答案外，另附口头回答版，便于面试时快速组织语言。

基础题（8 道）

FB-49-CO-B-001：什么是 WebAssembly？它和 JavaScript 的关系是什么？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请解释 WebAssembly 是什么，并说明它与 JavaScript 的关系。

参考答案：

核心要点：WebAssembly（简称 WASM）是一种面向 Web 的可移植、紧凑的二进制指令格式，可作为 C/C++、Rust、Go 等语言的编译目标，在现代浏览器中以接近原生的速度运行，并与 JavaScript 协同工作。

详细解释：

本质：WASM 不是一门编程语言，而是虚拟机指令集的底层表示。开发者通常用高级语言编写代码，再通过编译器生成 .wasm 二进制文件。
与 JavaScript 的关系：
- 互补而非替代：JS 负责应用框架、DOM 操作、异步 I/O；WASM 负责 CPU 密集型计算（图像处理、音视频编解码、加密、物理模拟等）。
- 同处于一个运行时：WASM 模块通过 JS API（WebAssembly 全局对象）加载、实例化，并调用宿主环境提供的 import。
- 互操作：JS 可以调用 WASM 导出的函数，WASM 也可以调用 JS 提供的 import 函数。
核心优势：体积小、解析快、执行效率高、安全沙箱、语言无关、可移植。

代码示例：

javascript

// 加载并实例化一个 WASM 模块
const response = await fetch('module.wasm');
const bytes = await response.arrayBuffer();
const { instance } = await WebAssembly.instantiate(bytes, {
  env: { abort: () => console.error('abort') }
});
console.log(instance.exports.add(2, 3)); // 5

最佳实践：

不要把整个前端应用都重写成 WASM，只把计算密集型热点下沉到 WASM。
优先评估算法复杂度和数据交换成本，再决定是否引入 WASM。

评分维度：

能说明 WASM 是二进制指令格式而非编程语言（35%）
能准确描述与 JS 的互补关系（35%）
能举例说明适用场景（30%）

常见错误：

认为 WebAssembly 会完全取代 JavaScript。
认为 WASM 可以直接操作 DOM（实际上需要通过 JS 代理）。
混淆 WASM 与 Flash、Java Applet 等插件技术。

延伸追问：

既然 WASM 性能高，为什么前端框架不用 WASM 重写？
WASM 的二进制格式相比 JS 源码有哪些体积和解析优势？

相关题目：

FB-49-CO-B-002 WebAssembly 的核心特点
FB-49-CO-B-004 如何在浏览器中加载 WASM 模块

参考资源：

口头回答版：

WebAssembly 是一种面向 Web 的二进制指令格式，可以把 C/C++、Rust 这些语言编译成 .wasm 文件在浏览器里跑。它和 JavaScript 不是替代关系，而是互补：JS 负责框架、DOM、网络这些，WASM 负责 CPU 密集型的计算，比如图像处理、加密、音视频。WASM 通过 JS 的 WebAssembly API 加载和实例化，双方可以互相调用函数。

FB-49-CO-B-002：WebAssembly 有哪些核心特点？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：49 WebAssembly 标签：WebAssembly、性能、安全 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请列举并解释 WebAssembly 的核心特点。

参考答案：

核心要点：WebAssembly 具有二进制格式、高效执行、安全沙箱、语言无关、可移植、开放标准六大核心特点。

详细解释：

特点	说明
二进制格式	`.wasm` 是紧凑的二进制指令流，比等价的 JS 文本体积小、解析速度快。
高效执行	接近原生机器码的执行效率，适合 CPU 密集型任务。
安全沙箱	运行在与 JS 相同的同源策略和 CSP 下，内存隔离、无任意内存访问、能力由 import 显式授予。
语言无关	C/C++、Rust、Go、C#、AssemblyScript、Zig 等均可编译到 WASM。
可移植	一次编译，可在所有支持 WASM 的浏览器和运行时上运行。
开放标准	W3C 推荐标准，由浏览器厂商、工具链厂商共同制定。

补充说明：

WASM 不直接提供 I/O、网络、文件系统能力，所有能力都需要通过 import 从宿主环境引入。
WASM 内存是一块连续的 ArrayBuffer（线性内存），模块不能直接访问 JS 堆，也不能被 JS 直接访问 WASM 内部栈。

评分维度：

能说出 4 个以上核心特点（50%）
能解释二进制格式和沙箱的含义（30%）
能说明语言无关和可移植的意义（20%）

常见错误：

认为 WASM 可以绕过同源策略。
认为 WASM 天然比 JS 快所有场景。
把 WASM 等同于某一门具体语言（如 Rust）。

延伸追问：

WASM 的沙箱与浏览器的同源策略有什么关系？
为什么说 WASM 是“安全”的？它有哪些安全边界？

相关题目：

FB-49-CO-B-001 什么是 WebAssembly
FB-49-SE-P-004 WebAssembly 的安全模型

参考资源：

口头回答版：

WebAssembly 主要有这几个特点：第一，它是二进制格式，体积小、解析快；第二，执行效率高，接近原生；第三，安全沙箱，运行在浏览器现有的安全模型里，内存是隔离的；第四，语言无关，C、Rust、Go 都能编译过去；第五，可移植，一次编译到处跑；第六，它是 W3C 开放标准。另外 WASM 本身没有 I/O 能力，想读文件、发请求都得通过 JS 提供的 import。

FB-49-CO-B-003：WASM 的编译流程是怎样的？WAT 和 WASM 是什么关系？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请描述 WebAssembly 的编译流程，并解释 .wat 和 .wasm 文件的关系。

参考答案：

核心要点：高级语言源代码经过编译器前端、WASM 文本格式（WAT）或直接生成二进制 WASM，最终由浏览器解析、验证、编译并实例化执行。

详细解释：

典型编译流程：

text

C/C++/Rust/AssemblyScript 源码
        ↓
   编译器前端（Clang/Rustc/asc）
        ↓
   生成 WASM 二进制 或 WAT 文本
        ↓
   浏览器/运行时：解码 → 验证 → 编译 → 实例化
        ↓
   通过 JS API 调用导出函数

WAT 与 WASM 的关系：
- .wasm：二进制格式，用于分发和执行。
- .wat：文本格式（WebAssembly Text Format），是 .wasm 的可读文本表示，使用 S-expression 语法。
- 二者可以互相转换，工具如 wasm2wat、wat2wasm。
浏览器内部处理流程：
- 解码（Decode）：把二进制解析成内部模块结构。
- 验证（Validate）：检查类型、栈平衡、内存边界等，确保模块安全。
- 编译（Compile）：把 WASM 指令编译为机器码或解释执行。
- 实例化（Instantiate）：分配内存、绑定 import、生成可调用实例。

代码示例（WAT）：

wat

(module
  (func $add (param $a i32) (param $b i32) (result i32)
    local.get $a
    local.get $b
    i32.add)
  (export "add" (func $add))
)

最佳实践：

日常开发使用高级语言编译生成 .wasm，调试时可导出 .wat 阅读。
使用 wasm-opt 等工具对二进制进行压缩和优化。

评分维度：

能描述从源码到执行的完整流程（40%）
能区分 WAT 和 WASM 的用途（30%）
能说明浏览器内部的验证/编译/实例化阶段（30%）

常见错误：

认为 WAT 是编译目标，WASM 是中间产物（实际相反）。
忽略验证阶段，认为浏览器直接执行任意二进制。
混淆编译器（如 Emscripten）和运行时（浏览器）。

延伸追问：

浏览器对 WASM 的验证具体检查哪些内容？
为什么 WAT 使用 S-expression 而不是类汇编语法？

相关题目：

FB-49-FS-P-001 WASM 二进制格式结构
FB-49-EN-A-006 Emscripten 胶水代码

参考资源：

口头回答版：

一般用 C、Rust 或者 AssemblyScript 写好源码，用编译器生成 .wasm 二进制文件。浏览器拿到之后，会先解码、再验证安全性、再编译成机器码，最后实例化，之后 JS 就能调用里面的函数了。WAT 是 WASM 的文本格式，相当于二进制的可读版，调试时常用，工具可以互相转换。

FB-49-CO-B-004：如何在浏览器中加载和实例化一个 WASM 模块？

题型：概念题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请说明在浏览器中加载和实例化 WebAssembly 模块的主要 API 和步骤。

参考答案：

核心要点：浏览器通过 WebAssembly 全局对象提供 compile、instantiate、compileStreaming、instantiateStreaming 等 API，用于加载、编译和实例化 WASM 模块。

详细解释：

主要 API 对比：

API	作用	适用场景
`WebAssembly.compile(bytes)`	仅编译模块	需要复用模块、Worker 间共享
`WebAssembly.instantiate(bytes, importObject)`	编译并实例化	一次性使用
`WebAssembly.compileStreaming(response)`	边下载边编译	大模块、减少等待
`WebAssembly.instantiateStreaming(response, importObject)`	边下载边编译并实例化	推荐用法
`new WebAssembly.Module(bytes)`	同步编译	小模块、Worker 中
`new WebAssembly.Instance(module, importObject)`	同步实例化	模块已编译完成

代码示例：

javascript

// 推荐方式：流式编译+实例化
const importObject = {
  env: {
    memory: new WebAssembly.Memory({ initial: 1 }),
    abort: () => { throw new Error('abort'); }
  }
};

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('module.wasm'),
  importObject
);

console.log(instance.exports.add(1, 2)); // 3

关键步骤：

准备 importObject，提供模块所需的 memory、table、function、global 等。
通过 fetch 获取 .wasm 文件。
调用 instantiateStreaming 流式编译并实例化。
通过 instance.exports 调用导出函数或访问导出内存。

最佳实践：

优先使用 instantiateStreaming，可缩短首字节到可执行的时间。
大模块在 Web Worker 中加载，避免阻塞主线程。
复用 WebAssembly.Module 可在多个 Worker/窗口间共享编译结果。

评分维度：

能说出 instantiate/instantiateStreaming 等核心 API（40%）
能说明 importObject 和 instance.exports 的作用（35%）
能写出基本加载示例（25%）

常见错误：

用 instantiate 代替 instantiateStreaming，浪费流式优化。
忘记提供必需的 import（如 memory），导致实例化失败。
把 Module 和 Instance 混为一谈。

延伸追问：

同一个 Module 可以实例化多次吗？有什么用？
如何在 Web Worker 中加载 WASM？

相关题目：

FB-49-CO-B-005 WASM 的 exports 和 imports
FB-49-PE-A-005 WASM 启动性能优化

参考资源：

口头回答版：

浏览器里通过 WebAssembly 全局对象来加载 WASM。最常用的推荐方式是 WebAssembly.instantiateStreaming(fetch('module.wasm'), importObject)，它可以边下载边编译。然后我们通过 instance.exports 调用导出的函数。实例化之前要先准备好 importObject，比如 memory、JS 函数这些。如果是大模块，建议在 Web Worker 里加载，避免卡主线程。

FB-49-CO-B-005：WASM 模块实例中的 exports 和 imports 是什么？

题目描述：请解释 WebAssembly 模块中的 exports 和 imports，并说明它们的作用。

参考答案：

核心要点：exports 是 WASM 模块暴露给宿主（JS）的函数、内存、表、全局变量；imports 是 WASM 模块向宿主请求的函数、内存、表、全局变量，用于完成 WASM 自身无法直接做的事。

详细解释：

exports（导出）：
- 由 WASM 模块定义，实例化后通过 instance.exports 访问。
- 类型包括：function、memory、table、global。
- JS 调用导出函数时，参数和返回值会自动在 JS 值与 WASM 值之间转换。
imports（导入）：
- WASM 模块声明自己需要外部提供的能力。
- 常见 import：
  - env.memory：共享线性内存，WASM 读写数据，JS 读取结果。
  - env.abort：宿主提供的错误处理函数。
  - wasi_snapshot_preview1.fd_write：WASI 标准 I/O。
为什么需要 imports：
- WASM 本身无 I/O、无 DOM、无网络，需要 JS 或运行时提供。
- 通过显式 import，安全边界清晰：WASM 只能做宿主允许的事。

代码示例：

javascript

const importObject = {
  env: {
    memory: new WebAssembly.Memory({ initial: 1, maximum: 4 }),
    // WASM 可以调用这个 JS 函数
    consoleLog: (value) => console.log('from wasm:', value)
  }
};

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('app.wasm'),
  importObject
);

instance.exports.run();

最佳实践：

设计清晰的 import 命名空间，避免命名冲突。
尽量减少高频 import 调用的开销，必要时批量处理。
对 import 函数做参数校验，防止恶意 WASM 模块滥用宿主能力。

评分维度：

能区分 exports 和 imports 的方向（40%）
能列举 exports/imports 的四种类型（30%）
能解释为什么 WASM 需要 imports（30%）

常见错误：

认为 WASM 可以直接访问 DOM 或网络，忽略 imports。
混淆 exports 和 imports 的方向。
忽略 memory 也可以 import/export。

延伸追问：

如果两个 WASM 模块需要共享内存，应该如何设计 imports/exports？
import 的函数调用有没有性能开销？如何优化？

相关题目：

FB-49-CO-A-001 WASM 线性内存
FB-49-CO-B-004 加载和实例化 WASM

参考资源：

口头回答版：

exports 是 WASM 模块暴露给 JS 的东西，比如函数、内存、表、全局变量，实例化后通过 instance.exports 拿到。imports 是 WASM 模块向外部请求的东西，因为 WASM 自己不能操作 DOM、不能发网络请求，所以需要 JS 通过 importObject 传给它。比如 memory、打印日志的函数、异常处理函数等。这样安全边界很清楚，WASM 只能做 JS 允许它做的事。

FB-49-CO-B-006：WebAssembly 支持哪些基本数据类型？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：中频 预计回答时长：2-3 分钟

题目描述：请列举 WebAssembly 支持的基本数据类型，并说明它们在 JS 互操作时的映射关系。

参考答案：

核心要点：WebAssembly 1.0 只支持四种数值类型：i32、i64、f32、f64。复杂数据（字符串、对象、数组）需要通过线性内存或表（Table）传递。

详细解释：

WASM 类型	说明	JS 映射	注意点
`i32`	32 位有符号/无符号整数	Number / BigInt	小整数和布尔常用
`i64`	64 位整数	BigInt	某些旧浏览器/JS 引擎可能不支持 BigInt 映射
`f32`	32 位 IEEE 754 浮点数	Number	精度较低，节省内存
`f64`	64 位 IEEE 754 浮点数	Number	默认浮点类型

复杂数据传递：

字符串：写入 WASM 线性内存，传递指针和长度给 JS；JS 读取内存并解码。
数组/结构体：序列化到线性内存，使用偏移量访问。
函数引用：通过 WebAssembly.Table 传递，实现回调或动态链接。

代码示例：

javascript

// 假设 WASM 返回一个指向字符串的指针
const ptr = instance.exports.getMessage();
const mem = new Uint8Array(instance.exports.memory.buffer);
let end = ptr;
while (mem[end] !== 0) end++;
const bytes = mem.slice(ptr, end);
const message = new TextDecoder().decode(bytes);
console.log(message);

最佳实践：

设计 WASM 接口时，优先使用数值参数，减少内存拷贝。
字符串/对象传递需要约定编码和内存布局。
使用工具链（如 Emscripten、wasm-bindgen）自动生成胶水代码，避免手写内存操作。

评分维度：

能说出四种基本类型（50%）
能说明 JS 映射关系（25%）
能解释复杂数据如何通过内存传递（25%）

常见错误：

认为 WASM 支持字符串、对象作为参数类型。
混淆 i64 在 JS 中的映射（需要使用 BigInt）。
忽略 f32/f64 的精度差异。

延伸追问：

如果要在 JS 和 WASM 之间传递一个 JSON 对象，你会怎么做？
WebAssembly 的引用类型（reference types）和垃圾回收提案解决了什么问题？

相关题目：

FB-49-CD-A-003 手写 JS 调用 WASM 传递字符串
FB-49-FS-P-005 WASM 内存管理与 GC

参考资源：

口头回答版：

WebAssembly 1.0 只有四种基本类型：i32、i64、f32、f64。传复杂数据比如字符串、数组、对象，需要把它们写到 WASM 的线性内存里，再传指针和长度给 JS。函数之间传回调可以用 Table。i64 在 JS 里对应 BigInt，f32 和 f64 都是 Number，但精度不一样。

FB-49-CA-B-007：下面代码的输出是什么？为什么？

题型：代码分析题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：49 WebAssembly 标签：WebAssembly、代码分析、性能 出现频率：中频 预计回答时长：3-5 分钟

题目描述：假设 math.wasm 中导出了一个函数 add，其签名等价于 (func (param i32) (param i32) (result i32))。请分析下面代码的输出。

javascript

async function main() {
  const { instance } = await WebAssembly.instantiateStreaming(
    fetch('math.wasm')
  );
  const add = instance.exports.add;

  console.log(add(1, 2));
  console.log(add(1.5, 2.5));
  console.log(add(2147483647, 1));
  console.log(add('3', '5'));
}
main();

参考答案：

核心要点：WASM 导出函数声明的参数类型和返回值类型会约束实际传入的 JS 值，JS 引擎会进行类型转换，可能出现截断、溢出或非预期结果。

详细解释：

add(1, 2) → 3：两个整数正常相加。
add(1.5, 2.5) → 3：JS 引擎把浮点数转换为 i32，小数部分被截断。
add(2147483647, 1) → -2147483648：32 位有符号整数溢出，回绕到最小值。
add('3', '5') → 8：字符串被强制转换为数字后相加。

关键机制：

WASM 函数签名在编译时确定，运行时调用会按签名做类型转换。
整数溢出在 WASM 中按补码回绕处理，不会抛异常（除非显式使用溢出检查扩展）。
与 JS 不同，WASM 不会在类型不匹配时抛出 TypeError，而是静默转换。

代码示例（修正版）：

javascript

// 调用前在 JS 层做类型校验
function safeAdd(a, b) {
  if (!Number.isInteger(a) || !Number.isInteger(b)) {
    throw new TypeError('arguments must be integers');
  }
  return instance.exports.add(a, b);
}

最佳实践：

在 JS 层对进入 WASM 的参数做边界检查。
对可能溢出的运算，在源码层使用饱和算术或显式检查。
工具链（如 AssemblyScript）可开启运行时检查，但会增加体积和开销。

评分维度：

能正确判断四个输出（40%）
能解释浮点截断和整数溢出机制（35%）
能提出参数校验方案（25%）

常见错误：

认为 WASM 会抛出类型错误。
忽略 32 位整数溢出回绕。
认为 add('3', '5') 会报错或返回 '35'。

延伸追问：

如果希望浮点数相加，WASM 函数签名应该怎么声明？
如何在 WASM 层面检测或避免整数溢出？

相关题目：

FB-49-CO-B-006 WASM 数据类型
FB-49-CA-A-008 WASM 内存越界分析

参考资源：

口头回答版：

第一行输出 3，正常整数相加。第二行输出 3，因为 WASM 函数参数是 i32，1.5 和 2.5 会被截断成 1 和 2。第三行输出 -2147483648，这是 32 位整数溢出的回绕结果。第四行输出 8，字符串被转成数字了。WASM 不会在类型错误时抛异常，而是静默转换，所以我们在 JS 层最好自己做参数校验。

FB-49-PE-B-008：WebAssembly 在哪些场景有性能优势？哪些场景不适合？

题型：性能优化题难度：🟢 基础 岗位层级：初级 / 高级 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：高频 预计回答时长：3-5 分钟

题目描述：请分析 WebAssembly 的性能优势场景，并说明哪些场景不适合使用 WASM。

参考答案：

核心要点：WASM 在 CPU 密集型、可并行化、计算逻辑稳定的任务上有优势；在频繁与 JS/内存交互、I/O 密集型、DOM 操作密集型场景中优势不明显甚至适得其反。

详细解释：

适合 WASM 的场景：

场景	示例	原因
数值计算	矩阵运算、科学计算、物理模拟	接近原生的指令执行效率
图像/音视频处理	滤镜、编解码、FFT	避免 JS 动态类型和 GC 波动
加密/哈希	SHA、AES、Argon2	稳定的执行时间
游戏引擎	物理、寻路、渲染计算	可复用 C/C++/Rust 生态
AI 推理	ONNX Runtime、TensorFlow.js backend	利用 SIMD、多线程潜力
文件解析	PDF 渲染、CAD 解析	已有大量 C++ 库可复用

不适合 WASM 的场景：

场景	原因
纯 DOM 操作	WASM 不能直接操作 DOM，需通过 JS 中转
大量小函数调用	JS↔WASM 边界调用有开销
频繁字符串/对象交换	需要内存拷贝和编解码
I/O 密集型	WASM 本身无 I/O，完全依赖 JS/宿主
简单业务逻辑	引入 WASM 增加构建复杂度和包体积

最佳实践：

先做性能基线测试，确认热点再迁移到 WASM。
把计算单元尽量做大，减少 JS↔WASM 调用次数。
结合 Web Worker 使用，避免阻塞主线程。

评分维度：

能列举 3 个以上适合场景并说明原因（50%）
能列举 3 个以上不适合场景（30%）
能提出评估和优化策略（20%）

常见错误：

认为所有场景 WASM 都比 JS 快。
忽略 JS↔WASM 数据交换成本。
把业务逻辑全部下沉到 WASM，导致维护困难。

延伸追问：

你如何评估一个功能是否值得用 WASM 重写？
WASM 与 Web Worker 配合时，通信开销如何优化？

相关题目：

FB-49-CO-B-001 什么是 WebAssembly
FB-49-PE-A-005 WASM 启动性能优化

参考资源：

口头回答版：

WASM 适合 CPU 密集型、计算稳定的任务，比如图像处理、音视频编解码、加密、物理模拟、AI 推理、游戏引擎这些。它不适合频繁操作 DOM、大量小函数调用、频繁传字符串对象、或者 I/O 密集型的场景，因为 WASM 和 JS 之间交换数据有开销。实际用之前要先做性能测试，把计算单元做大一点，减少来回调用。

进阶题（8 道）

FB-49-CO-A-001：WebAssembly 的线性内存（Linear Memory）是如何工作的？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请详细解释 WebAssembly 的线性内存模型，包括它的本质、增长机制、JS 如何读写以及多模块共享内存的方式。

参考答案：

核心要点：WebAssembly 的线性内存是一块连续的、可按页（64KB）增长的 ArrayBuffer，JS 和 WASM 都可以通过 TypedArray 读写，是两者交换复杂数据的主要通道。

详细解释：

本质：
- 线性内存是 WASM 模块的单一地址空间，所有 load/store 指令都通过它访问数据。
- 在 JS 侧表现为 WebAssembly.Memory 对象，其 .buffer 是一个 ArrayBuffer。
- 默认页大小为 64KB，初始页数由模块声明或 importObject 指定。
增长机制：
- 通过 memory.grow(deltaPages) 增加页数，返回旧的页数或 -1（失败）。
- 增长后，原来的 TypedArray 视图会失效，必须重新基于 memory.buffer 创建视图。
- 可声明 maximum 限制最大内存，便于引擎预分配连续空间。
JS 读写：

javascript

const memory = new WebAssembly.Memory({ initial: 1, maximum: 4 });
const view = new Uint8Array(memory.buffer);
view[0] = 72; // 'H'
view[1] = 105; // 'i'

// WASM 读取后可通过 export 返回结果

多模块共享内存：
- 多个 WASM 模块在实例化时传入同一个 WebAssembly.Memory 实例作为 import。
- 需要注意内存布局协议，避免互相覆盖。
- 结合 SharedArrayBuffer 可实现多线程 Worker 共享 WASM 内存。

最佳实践：

显式声明 maximum，提升安全性并允许引擎优化。
内存增长后，所有 TypedArray 视图需要重新创建。
对共享内存的访问需要同步原语（如 Atomics）。

评分维度：

能说明线性内存是 ArrayBuffer 及页式增长（40%）
能解释 JS 与 WASM 如何读写同一块内存（30%）
能说明共享内存和多模块协作方式（30%）

常见错误：

认为 WASM 可以直接访问 JS 堆内存。
内存增长后继续使用旧的 TypedArray 视图。
忽略 maximum 对安全性和性能的影响。

延伸追问：

如果 WASM 模块内存不足，如何优雅处理 memory.grow 失败？
多线程场景下，如何保证对 WASM 线性内存的线程安全？

相关题目：

FB-49-CD-A-003 手写 JS 调用 WASM 传递字符串
FB-49-FS-P-005 WASM 内存管理与 GC

参考资源：

口头回答版：

WASM 的线性内存本质上就是一块连续的 ArrayBuffer，一页 64KB，可以按页增长。JS 和 WASM 都能通过 TypedArray 读写它。内存增长要调用 memory.grow，增长后原来的视图会失效，需要重新创建。多个 WASM 模块要共享数据，可以传入同一个 Memory 对象。多线程场景还可以配合 SharedArrayBuffer 和 Atomics 使用。

FB-49-CO-A-002：WebAssembly 的 Table 是什么？有什么作用？

题型：概念题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释 WebAssembly 中 Table 的概念、用途，以及它为什么被设计为只读、不可直接索引的结构。

参考答案：

核心要点：WebAssembly.Table 是一个只读的函数引用表，WASM 模块可以通过索引间接调用其中的函数，主要用于实现函数指针、动态分发和跨模块函数共享，同时避免内存安全问题。

详细解释：

作用：
- 实现 C/C++ 中的函数指针。
- 支持间接调用（call_indirect），运行时根据索引决定调用哪个函数。
- 允许 WASM 调用 JS 提供的函数，或把 WASM 内部函数暴露给 JS/其他模块。
为什么只读：
- 如果允许通过内存地址直接存储函数指针，恶意代码可能把函数指针篡改到任意地址，破坏控制流。
- Table 存储在宿主（JS）控制的独立空间中，WASM 只能通过受控索引间接调用，无法直接修改表内容，保障了控制流完整性（CFI）。
代码示例：

javascript

const table = new WebAssembly.Table({
  element: 'anyfunc',
  initial: 2
});

const importObject = {
  env: { table }
};

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('app.wasm'),
  importObject
);

// JS 可以修改 table（但 WASM 不能直接修改）
table.set(0, instance.exports.foo);
table.set(1, instance.exports.bar);

// WASM 内部通过 call_indirect 选择调用

最佳实践：

需要函数指针或回调时，优先使用 Table 而不是手动在内存里存地址。
通过 initial 和 maximum 限制表大小。
理解 call_indirect 需要与 Table 中的函数签名匹配。

评分维度：

能说明 Table 是函数引用表（35%）
能解释函数指针和间接调用场景（35%）
能说明只读设计的安全原因（30%）

常见错误：

把 Table 和 Memory 混为一谈。
认为 WASM 可以直接修改 Table。
忽略 Table 对函数签名的匹配要求。

延伸追问：

Table 在实现 C++ 虚函数表时扮演什么角色？
多个 WASM 模块如何共享同一个 Table？

相关题目：

FB-49-CO-B-005 WASM 的 exports 和 imports
FB-49-FS-P-003 WASM 动态链接

参考资源：

口头回答版：

Table 是 WASM 里的函数引用表，主要用来实现函数指针和间接调用。WASM 可以通过索引去调用表里的函数，但自己不能直接修改表内容，只能由 JS 来改。这样设计是为了安全，防止恶意代码篡改函数指针破坏控制流。比如 C++ 的虚函数表、回调函数分发，都可以通过 Table 来实现。

FB-49-CD-A-003：手写 JS 调用 WASM 导出函数并传递字符串的示例

题型：手写代码题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、手写代码、性能 出现频率：高频 预计回答时长：5-10 分钟

题目描述：请手写一段 JavaScript 代码，调用一个 WASM 导出函数 greet(namePtr, nameLen)，并向其传递一个字符串参数。同时说明 WASM 内部如何读取该字符串。

参考答案：

核心要点：JS 和 WASM 之间传递字符串需要：JS 把字符串编码成字节，写入 WASM 线性内存，把指针和长度传给 WASM；WASM 根据指针读取内存中的字节并处理。

详细解释：

JS 侧流程：
- 使用 TextEncoder 将字符串编码为 UTF-8 字节。
- 把字节写入 WASM 线性内存的某个偏移位置。
- 调用 greet(ptr, len)。
WASM 侧流程：
- 根据 namePtr 从线性内存读取 nameLen 个字节。
- 处理或复制数据，避免被后续写入覆盖。

代码示例：

javascript

async function callGreet(name) {
  const { instance } = await WebAssembly.instantiateStreaming(
    fetch('greet.wasm')
  );

  const encoder = new TextEncoder();
  const bytes = encoder.encode(name);
  const len = bytes.length;

  // 在 WASM 内存中分配空间（示例直接放在偏移 16）
  const ptr = 16;
  const memory = new Uint8Array(instance.exports.memory.buffer);
  memory.subarray(ptr, ptr + len).set(bytes);

  // 调用 WASM 导出函数
  instance.exports.greet(ptr, len);
}

callGreet('WebAssembly');

WAT 侧读取示例：

wat

(module
  (memory (export "memory") 1)
  (func $greet (param $ptr i32) (param $len i32)
    ;; 实际处理：遍历 [ptr, ptr+len) 读取字节
    ;; 这里仅示意
  )
  (export "greet" (func $greet))
)

最佳实践：

使用工具链（Emscripten、wasm-bindgen）自动生成字符串传递代码，减少手写错误。
在 JS 侧做好内存分配管理，避免覆盖 WASM 正在使用的数据。
长字符串考虑零拷贝方案或分块处理。

评分维度：

能正确写出编码、写内存、传指针长度的流程（50%）
能解释 WASM 如何根据指针读取字符串（25%）
能提到内存分配和编码问题（25%）

常见错误：

试图直接把 JS 字符串作为参数传给 WASM。
忽略内存覆盖问题，写入地址与 WASM 栈冲突。
忘记使用 TextEncoder 处理 UTF-8 编码。

延伸追问：

如果字符串很长，怎样避免重复拷贝？
如何在 WASM 内部分配内存给 JS 写入？

相关题目：

FB-49-CO-A-001 WASM 线性内存
FB-49-CO-B-006 WASM 数据类型

参考资源：

口头回答版：

因为 WASM 只支持数字类型，传字符串需要先把字符串用 TextEncoder 编码成 UTF-8 字节，写到 WASM 的线性内存里，然后把指针和长度传给 WASM 的导出函数。WASM 内部根据指针和长度去内存里读字节。手写这个很容易出错，实际项目建议用 Emscripten 或 wasm-bindgen 自动生成胶水代码。

FB-49-CO-A-004：WASM 中的全局变量（Global）是什么？如何与 JS 共享？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：中频 预计回答时长：3-5 分钟

题目描述：请解释 WebAssembly 中 Global 的概念，说明它是如何作为模块级状态与 JavaScript 共享的。

参考答案：

核心要点：WebAssembly.Global 是模块级的可变或不可变全局变量，可在 JS 和 WASM 之间 import/export，用于共享配置、计数器、状态标志等简单状态。

详细解释：

Global 特点：
- 类型为 i32、i64、f32、f64 之一。
- 可声明为 mutable（可变）或不可变。
- 既可以作为 import 从 JS 传入，也可以作为 export 暴露给 JS。
与 JS 共享：

javascript

const sharedCounter = new WebAssembly.Global(
  { value: 'i32', mutable: true },
  0
);

const importObject = {
  env: { sharedCounter }
};

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('app.wasm'),
  importObject
);

// JS 和 WASM 都可以读写 sharedCounter
instance.exports.increment();
console.log(sharedCounter.value); // 读取 WASM 修改后的值

适用场景：
- 配置参数（如版本号、开关）。
- 简单计数器、状态标志。
- 多实例共享的全局状态。

最佳实践：

优先使用 immutable global，减少意外修改。
复杂状态建议通过线性内存或外部状态管理，而不是滥用 global。
注意多线程下 mutable global 的同步问题。

评分维度：

能说明 Global 是模块级变量（30%）
能解释 import/export 双向共享机制（40%）
能给出适用场景和注意事项（30%）

常见错误：

把 Global 当作普通 JS 变量，忽略其类型约束。
用 Global 传递复杂对象。
忽略 mutable global 的线程安全问题。

延伸追问：

Global 和 Memory 在共享状态方面有什么区别？
多实例共享同一个 Global 会有什么风险？

相关题目：

FB-49-CO-B-005 WASM 的 exports 和 imports
FB-49-CO-A-001 WASM 线性内存

参考资源：

口头回答版：

Global 是 WASM 的模块级全局变量，类型只能是 i32、i64、f32、f64 之一，可以是可变的也可以是不可变的。它可以作为 import 从 JS 传进去，也可以作为 export 暴露出来。适合共享一些简单的状态，比如配置、计数器。复杂状态还是建议走内存或者外部状态管理。

FB-49-PE-A-005：如何优化 WebAssembly 的启动时间和运行时性能？

题型：性能优化题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请从启动时间和运行时性能两个维度，说明如何优化 WebAssembly 应用。

参考答案：

核心要点：启动时间优化关注下载、解析、编译和实例化速度；运行时性能优化关注 JS↔WASM 边界开销、SIMD、多线程、内存布局和算法本身。

详细解释：

启动时间优化：

优化手段	说明
流式编译	使用 `instantiateStreaming` / `compileStreaming` 边下载边编译
压缩传输	服务器启用 gzip/brotli，减小 `.wasm` 体积
代码体积优化	使用 `wasm-opt`、LTO、禁用未使用功能
编译缓存	浏览器会自动缓存编译后的 WASM，合理设置缓存策略
延迟加载	非首屏需要的 WASM 按需加载
Web Worker	在后台线程编译和运行，避免阻塞主线程

运行时性能优化：

优化手段	说明
减少边界调用	把多个小函数合并，减少 JS↔WASM 往返
批量数据传递	一次传递大缓冲区，而不是多次传小数据
使用 SIMD	开启 `-msimd128` 等编译选项，利用向量指令
多线程	使用 SharedArrayBuffer + pthreads/wasm-threads
内存布局优化	结构体紧凑排列，减少 cache miss
避免频繁内存增长	预分配足够内存，减少 `memory.grow`
算法优化	选择更优算法，WASM 也受算法复杂度影响

代码示例：

javascript

// 流式加载 + Worker 编译
const worker = new Worker('wasm-worker.js');
worker.postMessage({ url: 'app.wasm' });

// wasm-worker.js
self.onmessage = async (e) => {
  const { instance } = await WebAssembly.instantiateStreaming(fetch(e.data.url));
  self.postMessage({ ready: true, exports: Object.keys(instance.exports) });
};

最佳实践：

使用 Chrome DevTools Performance 面板分析 WASM 启动耗时。
对热路径进行 A/B 测试，确认 WASM 版本确实有收益。
结合 WebAssembly.Module 缓存，多页面共享编译结果。

评分维度：

能说出 4 种以上启动优化手段（40%）
能说出 4 种以上运行时优化手段（40%）
能结合工具或代码示例说明（20%）

常见错误：

只关注运行时性能，忽略启动时间。
过度拆分函数，导致边界调用开销超过计算收益。
忽略 SIMD、多线程等新特性带来的额外收益。

延伸追问：

浏览器对 WASM 编译结果有缓存吗？如何利用？
多线程 WASM 需要哪些浏览器支持和安全限制？

相关题目：

FB-49-CO-B-004 加载和实例化 WASM
FB-49-PE-B-008 WASM 性能优势与适用场景

参考资源：

口头回答版：

启动时间优化可以用 instantiateStreaming 边下载边编译、服务器开 gzip/brotli、用 wasm-opt 减体积、延迟加载非首屏模块、放到 Web Worker 里编译。运行时优化要减少 JS 和 WASM 之间的调用次数、批量传数据、用 SIMD 和多线程、优化内存布局、避免频繁 memory.grow。总之要先做性能测试，确认热点再优化。

FB-49-EN-A-006：Emscripten 是什么？它的胶水代码（glue code）做了什么？

题型：工程化题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请解释 Emscripten 的定位，以及它生成的胶水代码（glue code）主要完成了哪些工作。

参考答案：

核心要点：Emscripten 是一个把 C/C++ 编译成 WebAssembly 的工具链，除了生成 .wasm 文件外，还会生成 JavaScript 胶水代码，负责加载模块、模拟 POSIX 环境、管理内存、桥接 C 运行时与浏览器 API。

详细解释：

Emscripten 定位：
- 基于 LLVM/Clang 的完整编译工具链。
- 支持将大量现有 C/C++ 库移植到 Web。
- 提供 emcc 命令行工具，使用方式类似 gcc/clang。
胶水代码的作用：

功能	说明
模块加载	封装 `WebAssembly.instantiateStreaming` 等 API
内存管理	创建 `WebAssembly.Memory`，实现 `malloc`/`free`
C 运行时	模拟文件系统（FS）、标准 I/O、setjmp/longjmp、异常处理
API 桥接	把 C 函数暴露为 JS 可调用接口，把 JS 函数注入为 C 可调用接口
主循环	模拟 `main` 函数执行和 `emscripten_set_main_loop`
pthreads	多线程支持需要 Special 的 pthread 代理文件

典型构建命令：

bash

emcc main.c -O3 -s WASM=1 -o app.js

这会生成 app.js（胶水代码）和 app.wasm（模块）。

与原生编译的区别：
- 编译目标不是本地机器码，而是 WASM + JS 运行时。
- 需要额外处理浏览器环境差异、同步加载限制、文件系统等。

最佳实践：

根据场景选择 -O2/-O3/-Os/-Oz 优化级别。
使用 -s MODULARIZE=1 生成可复用的模块工厂函数。
只导出需要的函数，减少胶水代码体积（-s EXPORTED_FUNCTIONS）。

评分维度：

能说明 Emscripten 是 C/C++ 到 WASM 的编译工具链（30%）
能列举胶水代码的 4 个以上职责（40%）
能写出基本构建命令或模块化配置（30%）

常见错误：

认为 Emscripten 只生成 .wasm 文件。
忽略胶水代码的体积和运行时开销。
把 Emscripten 的 JS 胶水代码当成普通业务代码打包，未评估其体积与初始化开销。

延伸追问：

-s MODULARIZE=1 和默认模式有什么区别？
如何减小 Emscripten 生成的 JS 胶水代码体积？

相关题目：

FB-49-CO-A-007 AssemblyScript 与 Rust 差异
FB-49-CP-P-007 WASI 是什么

参考资源：

口头回答版：

Emscripten 是一个把 C/C++ 编译成 WebAssembly 的工具链。它不仅生成 .wasm，还会生成一段 JS 胶水代码。胶水代码负责加载 WASM、创建内存、模拟 C 的运行时环境比如文件系统和标准输入输出、把 C 函数桥接到 JS、也注入 JS 函数给 C 调用。常用命令是 emcc main.c -O3 -s WASM=1 -o app.js。实际用的时候可以加 -s MODULARIZE=1 让生成的模块更规范。

FB-49-CO-A-007：AssemblyScript 和 Rust 在 WASM 开发中的定位与差异

题型：概念题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：中频 预计回答时长：5-8 分钟

题目描述：请对比 AssemblyScript 和 Rust 作为 WebAssembly 开发语言的定位、优势和适用场景。

参考答案：

核心要点：AssemblyScript 是 TypeScript 语法的 WASM 编译目标，适合前端团队快速上手；Rust 是系统级语言，配合 wasm-bindgen 适合高性能、需要复用现有生态的复杂项目。

详细解释：

维度	AssemblyScript	Rust
语法	类似 TypeScript	独立的系统级语言
学习曲线	低，前端团队易上手	高，需学习所有权、生命周期
运行时开销	小，无 GC（当前版本）	无 GC，内存安全由编译器保证
工具链	自研编译器，直接生成 WASM	wasm-pack、wasm-bindgen、cargo
生态复用	主要面向 WASM 新写代码	可复用 crates.io 上海量库
调试体验	相对简单，接近 TS	成熟，有丰富的 profiling 工具
包体积	通常较小	依赖 wasm-opt 优化后可控
典型场景	算法模块、游戏逻辑、简单计算	图像处理、加密、游戏引擎、复杂系统

示例对比：

typescript

// AssemblyScript
export function add(a: i32, b: i32): i32 {
  return a + b;
}

rust

// Rust + wasm-bindgen
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

选型建议：

AssemblyScript：前端团队、算法原型、需要快速交付、包体积敏感。
Rust：需要复用现有 C/C++/Rust 生态、对性能和安全性要求极高、团队有 Rust 能力。

评分维度：

能从语法、学习曲线、生态、工具链等维度对比（50%）
能给出明确的选型建议（30%）
能写出简单的代码示例（20%）

常见错误：

认为 AssemblyScript 就是 TypeScript，完全兼容所有 TS 特性。
认为 Rust 的 WASM 包一定比 AssemblyScript 大。
忽略团队技能栈对选型的影响。

延伸追问：

AssemblyScript 的 GC 提案进展如何？对现有代码有什么影响？
Rust 的 wasm-bindgen 自动处理了哪些 JS↔WASM 互操作细节？

相关题目：

FB-49-EN-A-006 Emscripten 胶水代码
FB-49-CP-R-007 WASM 在前端架构中的取舍

参考资源：

口头回答版：

AssemblyScript 就像 TypeScript 语法的 WASM 编译器，前端团队上手很快，适合做算法模块、游戏逻辑这种小模块。Rust 是系统级语言，配合 wasm-bindgen 工具链，性能更强，可以复用 crates.io 上的生态，适合做图像处理、加密、复杂引擎。选型要看团队能力和项目复杂度：想快速上手选 AssemblyScript，要复用生态和高性能选 Rust。

FB-49-CA-A-008：下面 WASM 内存操作代码会发生什么？如何排查？

题型：代码分析题难度：🟡 进阶 岗位层级：高级 / 专家 面试知识域：49 WebAssembly 标签：WebAssembly、代码分析、安全 出现频率：中频 预计回答时长：3-5 分钟

题目描述：假设某 WASM 模块导出的 readByte(offset) 函数会读取线性内存中 offset 位置的一个字节。请分析下面代码的行为，并说明如何排查。

javascript

const { instance } = await WebAssembly.instantiateStreaming(
  fetch('mem.wasm')
);
const mem = new Uint8Array(instance.exports.memory.buffer);

// WASM 内存初始为 1 页 = 64KB
console.log(instance.exports.readByte(0));      // ?
console.log(instance.exports.readByte(65535));  // ?
console.log(instance.exports.readByte(65536));  // ?
console.log(instance.exports.readByte(100000)); // ?

参考答案：

核心要点：WASM 的内存访问受线性内存边界保护，越界访问会触发运行时陷阱（trap），导致 JavaScript 抛出 RuntimeError。未初始化的合法地址读取到的是不确定值。

详细解释：

readByte(0)：
- 地址 0 在线性内存范围内（0 ~ 65535）。
- 如果该位置未被写入，读取结果是 不确定的零或随机值（取决于内存初始化状态）。
readByte(65535)：
- 1 页内存范围是 [0, 65535]，地址 65535 是合法的最后一个字节。
- 读取结果同样取决于初始化状态。
readByte(65536)：
- 等于 1 页大小，已经越界。
- WASM 运行时会抛出 WebAssembly.RuntimeError: memory access out of bounds。
- JS 调用栈会收到异常。
readByte(100000)：
- 明显越界，同样抛出 RuntimeError。

排查方法：

javascript

try {
  instance.exports.readByte(65536);
} catch (e) {
  if (e instanceof WebAssembly.RuntimeError) {
    console.error('WASM trap:', e.message);
  }
}

进阶排查：

在 DevTools 中开启 WASM 调试，查看反汇编和内存视图。
使用 -g 编译选项保留调试信息，关联源码。
检查 JS 传给 WASM 的指针/长度是否合法。
确认 memory.grow 后视图已刷新。

最佳实践：

在 JS 层对指针和长度做边界校验。
WASM 内部对关键函数使用显式检查（部分语言/工具链支持）。
保持合理的 initial/maximum 内存配置。

评分维度：

能正确判断四个调用的结果（40%）
能解释越界陷阱机制（30%）
能给出排查和防御方案（30%）

常见错误：

认为越界访问会返回 undefined 或 NaN。
忽略未初始化内存读取的不确定性。
在 memory.grow 后继续使用旧的 TypedArray 视图。

延伸追问：

WASM 的内存安全模型是如何防止访问 JS 堆或其他 WASM 模块内存的？
如果 WASM 内部发生 trap，如何定位到具体源码位置？

相关题目：

FB-49-CO-A-001 WASM 线性内存
FB-49-EN-P-006 如何调试 WASM

参考资源：

口头回答版：

前两个地址在 64KB 范围内，可以读，但读到的值取决于内存有没有初始化过。后面两个地址 65536 和 100000 都越界了，WASM 会抛出 WebAssembly.RuntimeError: memory access out of bounds。排查的时候要在 JS 层 try-catch，用 DevTools 的 WASM 调试看反汇编，也可以开 -g 保留调试信息。最关键是 JS 传给 WASM 的指针和长度要做边界检查。

深入题（7 道）

FB-49-FS-P-001：WebAssembly 模块的二进制格式结构是怎样的？

题型：框架原理题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：中频 预计回答时长：5-10 分钟

题目描述：请从高层次描述 WebAssembly 模块的二进制格式结构，说明它为什么采用 Section-based 设计，以及主要 Section 的作用。

参考答案：

核心要点：WASM 二进制文件由魔数（magic）、版本号、以及一系列 Section 组成。每个 Section 按类型编号（Type、Import、Function、Memory、Global、Export、Code、Data、Element 等）顺序排列，便于浏览器逐段解析和验证。

详细解释：

文件头部：
- Magic：0x00 0x61 0x73 0x6d（即 \0asm）。
- Version：0x01 0x00 0x00 0x00，表示 WASM 1.0。
Section 结构：

text

| Section ID | Section Size | Section Payload |

Section 必须按 ID 从小到大排列（除 Custom Section 可插入任意位置）。

主要 Section：

ID	Section	作用
0	Custom	调试信息、名称段、源码映射等
1	Type	函数类型签名
2	Import	导入的函数、内存、表、全局变量
3	Function	函数索引与类型索引的映射
4	Table	函数表定义
5	Memory	线性内存定义
6	Global	全局变量定义
7	Export	导出项
8	Start	自动执行的启动函数索引
9	Element	表初始化段
10	Code	函数体指令字节码
11	Data	线性内存初始化数据
12	DataCount	数据段数量（用于边界检查）

Section-based 设计的优点：
- 浏览器可以先解析 Type/Import 等元数据，再按需编译 Code Section。
- 支持流式编译：下载到 Code Section 即可开始编译。
- 工具链可以只修改某个 Section（如 Custom Section）而不影响其他部分。

代码示例（读取 Section 边界，示意）：

javascript

const buffer = await (await fetch('app.wasm')).arrayBuffer();
const view = new Uint8Array(buffer);
console.log('magic:', Array.from(view.slice(0, 4)).map(b => b.toString(16)));
console.log('version:', view[4], view[5], view[6], view[7]);

最佳实践：

发布生产环境时使用 wasm-opt 去除无用 Custom Section，减小体积。
调试构建保留 Custom Section 和 source map，便于定位问题。

评分维度：

能说明魔数、版本、Section 组成的整体结构（30%）
能列举 6 个以上主要 Section 及其作用（40%）
能解释 Section-based 设计的优势（30%）

常见错误：

认为 WASM 二进制是机器码直接执行。
混淆 Type Section 和 Function Section 的作用。
忽略 Section 必须有序排列的规则。

延伸追问：

Custom Section 通常包含什么？生产环境为什么要剥离？
Code Section 的函数体是如何编码局部变量和指令的？

相关题目：

FB-49-CO-B-003 WASM 编译流程
FB-49-FS-P-002 WASM 验证与实例化

参考资源：

口头回答版：

WASM 二进制文件开头是 4 个字节的魔数和 4 个字节的版本号，后面跟着一个个 Section。每个 Section 有 ID、大小和载荷。主要 Section 包括 Type、Import、Function、Memory、Global、Export、Code、Data、Element 这些。Section 必须按 ID 从小到大排，这样浏览器可以先读元数据再流式编译代码段。发布时一般会把 Custom Section 去掉减小体积。

FB-49-FS-P-002：WebAssembly 的验证（Validation）和实例化（Instantiation）过程是怎样的？

题目描述：请详细说明浏览器在加载 WASM 模块后，执行验证和实例化的过程，以及每个阶段可能产生的错误。

参考答案：

核心要点：WASM 模块在运行前要经历解码、验证、编译、实例化四个阶段。验证阶段进行静态类型和结构检查，实例化阶段分配资源并绑定 import/export，任何阶段失败都会阻止模块执行。

详细解释：

解码（Decode）：
- 解析二进制格式，检查魔数、版本、Section 顺序和基本结构。
- 失败：抛出 CompileError（如非法 Section ID、长度越界）。
验证（Validation）：
- 静态类型检查：函数参数/返回值类型匹配、操作数栈平衡。
- 边界检查：内存/表访问、数据段偏移、全局可变性。
- 导入导出一致性：import 类型与模块声明一致。
- 失败：抛出 WebAssembly.CompileError。
编译（Compile）：
- 把验证通过的 WASM 指令编译为特定 CPU 的机器码（或 JIT 中间表示）。
- 浏览器可能进行分层编译：先快速生成代码，再优化热路径。
实例化（Instantiate）：
- 分配 WebAssembly.Memory、Table、Global 等运行时资源。
- 绑定 importObject：类型必须完全匹配（包括可变性、签名）。
- 执行数据段和元素段初始化，调用 start 函数（如果有）。
- 失败：抛出 WebAssembly.LinkError（import 不匹配）或 RuntimeError（start 函数 trap）。

错误类型总结：

阶段	错误类型	典型原因
解码/验证	`CompileError`	非法指令、栈不平衡、类型不匹配
实例化	`LinkError`	import 缺失、类型不匹配、memory 不兼容
运行	`RuntimeError`	内存越界、整数除零、间接调用签名不匹配

代码示例：

javascript

try {
  await WebAssembly.instantiateStreaming(fetch('app.wasm'), importObject);
} catch (e) {
  if (e instanceof WebAssembly.CompileError) {
    console.error('模块验证失败:', e.message);
  } else if (e instanceof WebAssembly.LinkError) {
    console.error('实例化链接失败:', e.message);
  } else if (e instanceof WebAssembly.RuntimeError) {
    console.error('运行时错误:', e.message);
  }
}

最佳实践：

开发阶段保留调试信息，便于定位 CompileError。
生产环境对 importObject 做前置校验，避免 LinkError。
对运行时的 RuntimeError 做兜底捕获和降级。

评分维度：

能说清解码、验证、编译、实例化四个阶段（40%）
能区分 CompileError/LinkError/RuntimeError（30%）
能给出错误处理和调试建议（30%）

常见错误：

认为 WASM 加载失败只有一种错误类型。
把验证错误和运行时错误混为一谈。
忽略 import 类型匹配导致实例化失败。

延伸追问：

验证阶段为什么要检查操作数栈平衡？
实例化时 start 函数的执行顺序是怎样的？

相关题目：

FB-49-FS-P-001 WASM 二进制格式
FB-49-CA-A-008 WASM 内存越界分析

参考资源：

口头回答版：

WASM 运行前要经历解码、验证、编译、实例化四个阶段。解码是解析二进制；验证是做静态类型检查、栈平衡、边界检查；编译是把指令转成机器码；实例化是分配内存、绑定 import、初始化数据段。不同阶段出错会抛不同类型的错误：验证阶段是 CompileError，实例化 import 不匹配是 LinkError，运行中越界是 RuntimeError。实际开发要对这些错误分别处理。

FB-49-FS-P-003：WebAssembly 如何实现动态链接和模块间调用？

题目描述：请说明 WebAssembly 中动态链接（dynamic linking）和模块间函数调用的实现方式，以及实际项目中的常见方案。

参考答案：

核心要点：WASM 本身没有内置的“动态链接器”，动态链接通过共享 Memory、共享 Table 以及 import/export 机制实现。工具链（Emscripten、wasm-bindgen）提供了主模块/副模块（main/side module）等高层抽象。

详细解释：

底层机制：
- 共享 Memory：多个 WASM 模块 import 同一个 WebAssembly.Memory，共享堆空间。
- 共享 Table：多个模块 import 同一个 WebAssembly.Table，实现跨模块函数指针和间接调用。
- import/export：模块 A 导出的函数可以作为模块 B 的 import。
典型模式：

javascript

const memory = new WebAssembly.Memory({ initial: 2, maximum: 10 });
const table = new WebAssembly.Table({ element: 'anyfunc', initial: 1, maximum: 10 });

const sharedEnv = { memory, table };

// 加载动态库模块
const lib = await WebAssembly.instantiateStreaming(fetch('lib.wasm'), { env: sharedEnv });

// 主模块导入动态库导出的函数
const mainImport = {
  env: sharedEnv,
  lib: lib.exports
};

const main = await WebAssembly.instantiateStreaming(fetch('main.wasm'), mainImport);
main.exports.run();

Emscripten 方案：
- 主模块（main module）：包含动态链接器和完整运行时。
- 副模块（side module）：动态加载的共享库，使用 -s SIDE_MODULE=1 编译。
- 通过 dlopen/dlsym 在运行时加载。
注意事项：
- 需要统一 ABI（调用约定、内存布局、Table 索引协议）。
- 动态链接增加了复杂性和包管理成本。
- 浏览器端通常更倾向于静态链接以简化部署。

最佳实践：

简单场景优先静态链接，减少运行时复杂度。
需要插件化或按需加载时，使用 Emscripten 的 side module 或自定义 import 映射。
对共享内存做严格版本和 ABI 管理。

评分维度：

能说明动态链接通过共享 Memory/Table/import 实现（40%）
能解释 Emscripten main/side module 模式（30%）
能说明 ABI 统一和版本管理的重要性（30%）

常见错误：

认为 WASM 原生支持 dlopen 一样的动态链接。
忽略不同编译器生成模块的 ABI 兼容性问题。
动态加载后未检查 import 类型匹配。

延伸追问：

多个模块共享 Table 时，如何分配索引避免冲突？
动态链接对启动性能和内存占用有什么影响？

相关题目：

FB-49-CO-A-001 WASM 线性内存
FB-49-CO-A-002 WASM Table

参考资源：

口头回答版：

WASM 本身没有内置动态链接器，动态链接一般通过共享同一个 Memory 和 Table，再加上 import/export 来实现。Emscripten 提供了主模块和副模块的模式，主模块带动态链接器，副模块用 SIDE_MODULE=1 编译，运行时通过 dlopen 加载。实际项目里要注意 ABI 统一，不同编译器生成的模块可能不兼容。浏览器端为了简单，通常还是优先静态链接。

FB-49-SE-P-004：WebAssembly 的安全模型与沙箱机制是怎样的？

题型：安全题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：49 WebAssembly 标签：WebAssembly、安全、安全 出现频率：高频 预计回答时长：5-10 分钟

题目描述：请详细说明 WebAssembly 的安全模型，包括沙箱边界、内存隔离、能力模型（Capability-based）以及常见安全风险。

参考答案：

核心要点：WebAssembly 采用基于能力（Capability-based）的安全模型：模块默认没有任何能力，所有 I/O、网络、文件系统、DOM 访问都必须通过显式 import 获得。线性内存和 Table 的隔离进一步限制了模块行为。

详细解释：

沙箱边界：
- WASM 运行在浏览器已有的同源策略（SOP）和内容安全策略（CSP）框架内。
- 默认无法访问网络、文件系统、DOM、本地存储等。
- 只能通过宿主提供的 import 函数获得受限能力。
内存隔离：
- 每个 WASM 模块只能访问自己的线性内存（或显式共享的内存）。
- 无法直接读取 JS 堆、其他 WASM 模块内存或浏览器进程内存。
- 越界访问会触发 trap，不会破坏外部内存。
能力模型（Capability-based Security）：
- 模块需要声明自己 import 什么。
- 宿主在实例化时决定是否授予这些能力。
- 即使模块包含恶意代码，没有 import 也无法执行危险操作。
常见安全风险：

风险	说明	防御
侧信道攻击	Spectre/Meltdown 类时序攻击	站点隔离、COOP/COEP、减少高精度计时
import 滥用	恶意模块调用宿主提供的能力	最小权限原则，严格校验 import 函数
反混淆绕过	WASM 二进制可被反编译分析	代码混淆、服务端核心逻辑
拒绝服务	无限循环、大量内存申请	限制执行时间、内存上限
供应链风险	第三方 WASM 库携带漏洞	依赖审计、SBOM、签名验证

最佳实践：

遵循最小权限原则，只暴露必要的 import。
对 WASM 来源做 SRI（Subresource Integrity）校验。
使用 CSP 限制 script-src 和 wasm-src（未来支持）。
关键逻辑不要完全依赖客户端 WASM 安全，服务端仍需校验。

评分维度：

能解释能力模型和沙箱边界（40%）
能说明内存隔离机制（25%）
能列举 3 个以上安全风险及防御措施（35%）

常见错误：

认为 WASM 比 JS 更安全，可以完全替代服务端验证。
认为 WASM 沙箱可以绕过同源策略。
忽略第三方 WASM 供应链风险。

延伸追问：

WASM 如何应对 Spectre 这类侧信道攻击？
如果 WASM 模块需要网络访问，应该如何安全地授予能力？

相关题目：

FB-49-CO-B-002 WASM 核心特点
FB-49-CA-A-008 WASM 内存越界分析

参考资源：

口头回答版：

WASM 的安全模型是基于能力的：模块默认什么都不能做，所有能力都要通过 import 显式获取。内存是隔离的，WASM 只能访问自己的线性内存，越界会 trap。它运行在浏览器的同源策略和 CSP 下，不能绕过这些限制。常见风险包括侧信道攻击、import 被滥用、拒绝服务、供应链风险等。防御上要对 import 做最小权限、校验来源、限制内存和执行时间，关键逻辑服务端再验一次。

FB-49-FS-P-005：WebAssembly 的内存管理与垃圾回收机制是怎样的？

题型：框架原理题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：中频 预计回答时长：5-10 分钟

题目描述：请说明 WebAssembly 1.0 的内存管理模型，以及 WebAssembly GC 提案目前的进展和意义。

参考答案：

核心要点：WebAssembly 1.0 没有内置垃圾回收器，内存由模块自身通过 malloc/free 或语言级 GC（如 AssemblyScript 的 RC、Rust 的所有权）管理。WASM GC 提案旨在让 WASM 直接管理结构化对象，减少与 JS 堆交互开销。

详细解释：

WASM 1.0 内存管理：
- 线性内存是一块连续的字节数组，WASM 通过 load/store 访问。
- 语言工具链负责在自己的线性内存中实现分配器：
  - C/C++：使用 malloc/free 或 Emscripten 的 dlmalloc。
  - Rust：编译时所有权检查，运行时使用自定义分配器。
  - AssemblyScript：使用引用计数（RC）管理对象。
JS↔WASM 对象传递问题：
- WASM 对象对 JS 不透明，JS 只能看到数字指针。
- 需要手动管理对象生命周期，容易出现悬空指针或内存泄漏。
- 工具链通过 glue code 封装对象句柄（handle）来简化。
WASM GC 提案：
- 引入结构化类型（struct、array）和托管引用（managed reference）。
- 由 WASM 运行时提供垃圾回收器。
- 意义：
  - 减少语言工具链自行实现 GC 的复杂度。
  - 让 Java、Kotlin、C# 等带 GC 语言更容易编译到 WASM。
  - 改善与 JS 对象的互操作性。
现状：
- WASM GC 提案已进入 Phase 4，部分浏览器开始实现。
- 正式发布前，生产环境仍依赖各语言自身的内存管理策略。

最佳实践：

明确 WASM 对象所有权和生命周期，避免跨边界泄漏。
使用工具链提供的 free 或 drop 接口释放资源。
关注 WASM GC 提案进展，未来可简化内存管理。

评分维度：

能说明 WASM 1.0 无内置 GC，依赖工具链管理（35%）
能解释 JS↔WASM 对象生命周期问题（25%）
能说明 WASM GC 提案的目标和意义（40%）

常见错误：

认为 WASM 自动管理内存。
把 WASM 内存泄漏归咎于浏览器。
认为 WASM GC 提案会取代所有语言级内存管理。

延伸追问：

Rust 的所有权模型在 WASM 中如何体现？
如果 WASM 模块分配的对象需要长期被 JS 持有，如何设计释放策略？

相关题目：

FB-49-CO-A-001 WASM 线性内存
FB-49-CD-A-003 JS 调用 WASM 传递字符串

参考资源：

口头回答版：

WASM 1.0 本身没有垃圾回收器，线性内存里的对象由各语言工具链自己管理。C/C++ 用 malloc/free，Rust 靠所有权，AssemblyScript 用引用计数。JS 拿到的 WASM 对象其实是指针，生命周期要手动管理，很容易泄漏。WASM GC 提案正在推进，目标是让 WASM 直接支持结构化类型和托管引用，这样带 GC 的语言更容易编译到 WASM，也能减少手写内存管理的麻烦。

FB-49-EN-P-006：如何调试 WebAssembly？有哪些工具和方法？

题型：工程化题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：49 WebAssembly 标签：WebAssembly、调试 出现频率：中频 预计回答时长：5-10 分钟

题目描述：请介绍调试 WebAssembly 的主要工具和方法，包括浏览器调试、源码映射、日志输出和性能分析。

参考答案：

核心要点：WASM 调试需要保留调试信息（DWARF/source map），借助浏览器 DevTools、WABT 工具链、语言工具链的调试输出，以及性能分析工具定位问题。

详细解释：

浏览器 DevTools：
- Chrome/Edge/Firefox 支持 WASM 调试，可设置断点、查看局部变量、单步执行。
- 配合 DWARF 调试信息，可把二进制指令映射回 C/C++/Rust 源码。
- DevTools Memory 面板可观察 WASM 内存占用。
DWARF 与 Source Map：
- 编译时加 -g（Emscripten）或 --debug（wasm-pack）保留 DWARF 信息。
- 浏览器读取内嵌 DWARF Section，实现源码级调试。
- Source map 主要用于 JS glue code。
WABT 工具链：
- wasm2wat：把二进制转成文本格式阅读。
- wasm-objdump：查看 Section、导出导入、代码结构。
- wasm-decompile：生成类 C 伪代码，辅助理解。
日志与运行时诊断：
- 通过 import 注入 console.log 到 WASM。
- 使用 console.trace 捕获调用栈。
- 在 JS 层捕获 WebAssembly.RuntimeError。
性能分析：
- Chrome DevTools Performance 面板分析编译、实例化、执行耗时。
- 使用 chrome://tracing 或 about:tracing 查看 V8 内部 WASM 编译细节。

代码示例（Emscripten 保留调试信息）：

bash

emcc main.c -O0 -g -s WASM=1 -o app.js

最佳实践：

开发环境保留 DWARF，生产环境剥离调试信息。
对复杂问题先在 WAT 层面理解指令流程。
性能问题优先用 Performance 面板确认热点。

评分维度：

能说出浏览器 DevTools + DWARF 源码级调试（35%）
能列举 WABT 工具链的常用工具（25%）
能说明日志注入、错误捕获和性能分析方法（40%）

常见错误：

生产环境保留大量调试信息，导致体积膨胀。
只用 console.log 硬调试，不利用源码级调试。
忽略 RuntimeError 的调用栈信息。

延伸追问：

如何在 DevTools 中查看 WASM 模块的线性内存内容？
如果线上出现 WASM 崩溃，如何收集有效的诊断信息？

相关题目：

FB-49-CA-A-008 WASM 内存越界分析
FB-49-FS-P-002 WASM 验证与实例化

参考资源：

口头回答版：

调试 WASM 主要靠浏览器 DevTools，配合 DWARF 调试信息可以把二进制指令映射回源码。编译时加 -g 保留调试信息。还可以用 WABT 工具链，比如 wasm2wat 看文本格式、wasm-objdump 看结构。日志方面可以通过 import 注入 console.log 到 WASM。性能问题用 DevTools Performance 面板看编译和运行耗时。生产环境记得把调试信息剥离掉。

FB-49-CP-P-007：WASI 是什么？它和 WebAssembly 有什么关系？

题型：综合开放题难度：🔴 深入 岗位层级：专家 / 架构师 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：中频 预计回答时长：5-10 分钟

题目描述：请解释 WASI 的定位、设计目标，以及它与 WebAssembly 和浏览器环境的关系。

参考答案：

核心要点：WASI（WebAssembly System Interface）是 WebAssembly 的模块化系统接口标准，让 WASM 模块能够以可移植、安全的方式访问文件、网络、时钟、随机数等操作系统能力，不仅限于浏览器，也可用于服务端和边缘计算。

详细解释：

为什么需要 WASI：
- WASM 1.0 只有数值计算能力，没有标准化的 I/O 接口。
- 不同宿主（浏览器、Node.js、Wasmtime、Wasi-sdk）提供的 API 不一致。
- WASI 提供跨宿主的标准系统接口，增强可移植性。
设计目标：
- 可移植：同一 WASM 模块可在浏览器、云端、IoT 等环境运行。
- 安全：基于能力模型，模块只能访问被授予的资源（如特定目录）。
- 模块化：按功能划分标准模块（如 wasi-io、wasi-filesystem、wasi-sockets）。
与浏览器的关系：
- 浏览器环境不完全支持 WASI，因为浏览器有自己的安全模型和 API（Fetch、IndexedDB 等）。
- 浏览器中的 WASI 子集可通过 polyfill 实现。
- Node.js 对 WASI 的支持更成熟，可通过 wasi 模块运行。
WASI Preview1 与 Preview2：
- Preview1：基于 POSIX 风格，以模块导入形式提供系统调用。
- Preview2：基于组件模型（Component Model），引入 WIT（WASM Interface Types），支持更丰富的类型和组合能力。

代码示例（Node.js 运行 WASI）：

javascript

import { readFile } from 'node:fs/promises';
import { WASI } from 'wasi';

const wasi = new WASI({
  version: 'preview1',
  args: process.argv,
  env: process.env,
  preopens: { '/sandbox': '/some/real/path' }
});

const wasm = await WebAssembly.compile(await readFile('./app.wasm'));
const instance = await WebAssembly.instantiate(wasm, wasi.getImportObject());
wasi.start(instance);

最佳实践：

浏览器内 I/O 需求优先使用浏览器原生 API，WASI 作为补充。
服务端/边缘场景可积极采用 WASI 提升可移植性。
关注 WASI Preview2 和 Component Model 的发展。

评分维度：

能说明 WASI 是 WASM 的系统接口标准（35%）
能解释可移植、安全、模块化的设计目标（35%）
能区分浏览器和 Node.js 对 WASI 的支持差异（30%）

常见错误：

认为 WASI 是浏览器 DOM API 的替代品。
混淆 WASI 与 Emscripten 的虚拟文件系统。
认为所有浏览器都原生支持完整 WASI。

延伸追问：

WASI 的能力模型如何限制模块只能访问指定目录？
Component Model 和 WIT 对 WASM 生态会有什么影响？

相关题目：

FB-49-EN-A-006 Emscripten 胶水代码
FB-49-SD-R-006 设计 WASM 插件平台

参考资源：

口头回答版：

WASI 是 WebAssembly 的系统接口标准，解决 WASM 怎么跨平台访问文件、网络、时钟这些系统能力的问题。它设计上是可移植、安全、模块化的，模块只能访问被授权的资源。WASI 不只是给浏览器用的，服务端、边缘计算、IoT 都能用。浏览器里 WASI 支持有限，Node.js 支持得更好。现在 WASI 正在向 Preview2 和 Component Model 演进，未来类型系统和组合能力会更强。

架构题（32 道）

FB-49-SC-R-001：如何设计一个前端图像处理系统，引入 WebAssembly 进行计算加速？

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、Web Worker、性能 出现频率：高频 预计回答时长：15-20 分钟

题目描述：假设你需要在前端实现一个图像处理应用，支持滤镜、缩放、旋转、水印等操作。请设计整体架构，说明 WebAssembly 在其中的角色、与 JavaScript 的协作方式，以及如何保证性能和用户体验。

参考答案：

核心要点：将图像的像素计算密集型操作下沉到 WASM，JS 负责 UI、文件 I/O、Canvas 渲染和任务调度；通过 Web Worker 避免阻塞主线程；采用 SharedArrayBuffer 或 Transferable Objects 减少数据拷贝。

详细解释：

整体架构：

text

┌─────────────────────────────────────────────────────┐
│  UI Layer (React/Vue)                               │
│  - 上传组件、参数面板、预览、进度条                  │
└──────────────────┬──────────────────────────────────┘
                   │  postMessage + Transfer
┌──────────────────▼──────────────────────────────────┐
│  Worker Layer                                       │
│  - 接收 ImageData / ArrayBuffer                     │
│  - 加载 WASM 模块，调用图像处理函数                  │
└──────────────────┬──────────────────────────────────┘
                   │  Memory / import
┌──────────────────▼──────────────────────────────────┐
│  WASM Layer (Rust/C/AssemblyScript)                 │
│  - 像素级算法：滤镜、缩放、旋转、混合                │
└─────────────────────────────────────────────────────┘

JS 与 WASM 协作：
- JS 从 input[type=file] 元素读取图片，解码为 ImageData。
- 将 ImageData.data（Uint8ClampedArray）传入 Worker。
- Worker 把像素数据写入 WASM 线性内存，调用处理函数。
- WASM 处理完成后，Worker 把结果传回主线程，主线程绘制到 Canvas。
性能优化：
- 使用 Web Worker 避免主线程阻塞。
- 使用 Transferable Objects 转移 ArrayBuffer 所有权，避免拷贝。
- 对算法使用 SIMD 和多线程（SharedArrayBuffer）。
- 流式加载 WASM，优先实例化核心滤镜模块。
用户体验：
- 处理大图片时显示进度条（WASM 通过 import 回调报告进度）。
- 提供降级方案：WASM 加载失败时使用纯 JS 实现。
- 支持取消操作（Worker 终止或共享状态标志）。

代码示例（Worker 中调用 WASM）：

javascript

// image-worker.js
self.onmessage = async (e) => {
  const { imageData, filter } = e.data;
  const { instance } = await WebAssembly.instantiateStreaming(fetch('image.wasm'));

  const size = imageData.data.length;
  const ptr = instance.exports.alloc(size);
  new Uint8Array(instance.exports.memory.buffer, ptr, size).set(imageData.data);

  instance.exports.applyFilter(ptr, size, filter);

  const result = new Uint8ClampedArray(instance.exports.memory.buffer, ptr, size).slice();
  instance.exports.free(ptr);

  self.postMessage({ result }, [result.buffer]);
};

评分维度：

能清晰划分 JS 和 WASM 的职责（30%）
能说明 Worker、Transferable、SIMD 等性能优化手段（35%）
能考虑降级、取消、进度反馈等用户体验（25%）
能给出代码或架构图示例（10%）

常见错误：

在主线程直接处理大图片，导致 UI 卡顿。
每次处理都完整拷贝像素数据，不利用 Transferable。
WASM 模块设计过细，导致频繁 JS↔WASM 调用。

延伸追问：

如果图片分辨率非常高，如何分块处理避免内存爆炸？
如何处理不同浏览器对 SIMD 和多线程的支持差异？

相关题目：

FB-49-PE-A-005 WASM 启动性能优化
FB-49-SC-R-004 WASM 与 WebGL 游戏引擎

参考资源：

口头回答版：

我会把图像处理分成三层：UI 层用 JS 框架负责上传、预览、参数面板；Worker 层负责加载 WASM 和调度任务；WASM 层负责像素级计算。JS 把 ImageData 通过 Transferable Objects 传给 Worker，Worker 写到 WASM 内存，处理完再传回主线程画到 Canvas。WASM 加载用 instantiateStreaming，大任务放 Worker 避免卡主线程。还要做降级方案，WASM 失败时回退到 JS 实现，并给用户进度条和取消按钮。

FB-49-SC-R-002：设计一个浏览器端视频编解码方案，WebAssembly 扮演什么角色？

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、Web Worker、性能 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个浏览器端视频剪辑/转码方案，说明 WebAssembly 适合做什么、不适合做什么，以及如何与 WebCodecs、WebGL/WebGPU 协作。

参考答案：

核心要点：WebAssembly 适合执行可移植的编解码算法和滤镜处理，但受限于性能和功耗，浏览器原生 API（WebCodecs、VideoDecoder/VideoEncoder）应优先用于硬解/硬编；WASM 作为算法回退和自定义处理补充。

详细解释：

整体架构：

text

┌────────────────────────────────────────────┐
│  UI / Timeline (JS)                        │
└──────────────┬─────────────────────────────┘
               │
┌──────────────▼─────────────────────────────┐
│  Media Pipeline                            │
│  - WebCodecs: 硬件解码/编码                │
│  - WASM: 自定义滤镜、格式封装、软解回退    │
│  - WebGL/WebGPU: 渲染、GPU 加速            │
└────────────────────────────────────────────┘

WASM 的角色：
- 自定义编码器/解码器：如特定格式软解、私有协议。
- 滤镜和后处理：色彩调整、去噪、叠加。
- 容器封装：MP4、WebM 封装/解封装（如 FFmpeg WASM）。
- 回退方案：当 WebCodecs 不支持某格式时启用。
不适合 WASM 直接做的事：
- 大规模 H.264/H.265/AV1 实时硬解：应使用 WebCodecs 调用平台能力。
- 直接操作视频帧渲染：通过 WebGL/WebGPU 纹理上传更高效。
- 持续高码率实时编码：功耗和性能通常不如原生硬编。
协作方式：
- 解码：WebCodecs 输出 VideoFrame，转换为 ArrayBuffer 后传给 WASM 处理。
- 编码：WASM 处理后的原始帧交给 WebCodecs 编码器。
- 渲染：处理结果上传到 WebGL texture 或 Canvas 2D。

最佳实践：

优先使用 WebCodecs 和硬件加速，WASM 处理算法差异化部分。
在 Worker 中运行 WASM 编解码，避免阻塞 UI。
对实时场景严格控制帧率和缓冲区大小，防止内存增长。

评分维度：

能明确 WASM、WebCodecs、WebGL 各自职责（40%）
能说明 WASM 的适用边界和回退场景（30%）
能设计 Worker 流水线并考虑内存/功耗（30%）

常见错误：

试图用 WASM 完全替代 WebCodecs 做硬解。
忽略视频帧数据在 JS↔WASM 间拷贝的巨大开销。
未做实时场景下的背压和内存控制。

延伸追问：

如果需要在 WASM 中集成 FFmpeg，如何控制包体积？
WebCodecs 和 WASM 软解在延迟和画质上如何取舍？

相关题目：

FB-49-SC-R-001 前端图像处理系统
FB-49-SC-R-005 AI 推理中 WASM 与 WebGPU 协作

参考资源：

口头回答版：

浏览器端视频处理我会优先用 WebCodecs 做硬解硬编，WASM 做自定义滤镜、特殊格式软解、容器封装这些补充工作。WASM 直接做大规模实时硬解是不合适的，性能和功耗都比不上原生。数据流是：WebCodecs 解码出 VideoFrame，转成 ArrayBuffer 给 WASM 处理，处理完再通过 WebCodecs 编码，或者上传到 WebGL 渲染。整个编解码流水线放在 Worker 里，避免卡 UI，还要控制内存和帧缓冲。

FB-49-SC-R-003：如何在大型前端项目中组织 WASM 模块的构建、加载与版本管理？

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、模块化 出现频率：中频 预计回答时长：15-20 分钟

题目描述：在一个大型前端项目中，多个业务线都需要使用 WASM 模块。请设计 WASM 模块的构建、加载和版本管理方案。

参考答案：

核心要点：将 WASM 模块作为独立包发布，统一构建流水线，提供 JS 封装层；加载策略按业务场景分为同步预加载、异步按需加载和 Worker 加载；版本管理通过 npm/内部 registry + 语义化版本 + SRI 校验实现。

详细解释：

构建层：

text

packages/
├── wasm-core/          # 核心算法库（Rust/C）
├── wasm-image/         # 图像处理模块
├── wasm-crypto/        # 加密模块
└── wasm-bridge/        # 统一 JS 封装层

每个 WASM 包独立仓库或 Monorepo 子包。
使用 wasm-pack、Emscripten 或自定义构建脚本统一输出 .wasm + .js + .d.ts。
CI 中运行 wasm-opt 优化、测试、生成 SBOM。

JS 封装层：
- 隐藏 instantiateStreaming、内存管理、字符串编解码细节。
- 提供 Promise-based API，支持加载状态、错误处理和超时。
- 示例：

typescript

import { ImageProcessor } from '@corp/wasm-image';

const processor = await ImageProcessor.load('/assets/wasm-image.wasm');
const result = await processor.applyFilter(imageData, 'grayscale');

加载策略：
- 预加载：首屏关键模块用 link rel=preload 声明或 instantiateStreaming 提前加载。
- 按需加载：非关键模块用动态 import() 加载。
- Worker 加载：大计算量模块在 Worker 中实例化。
版本管理：
- 语义化版本（semver），重大 ABI 变更升级主版本。
- 构建产物带内容哈希，CDN 长期缓存。
- SRI（Subresource Integrity）校验防止篡改。
- 运行时版本兼容性检查，ABI 不匹配时拒绝实例化并提示升级。

最佳实践：

WASM 包不要直接暴露裸 instance.exports，统一封装。
对 WASM 模块做单元测试和集成测试，覆盖边界条件。
记录每个版本的 ABI 变更日志。

评分维度：

能设计清晰的包结构和构建流水线（35%）
能说明加载策略和 JS 封装层设计（30%）
能提出版本管理、缓存、SRI 等工程化措施（35%）

常见错误：

每个业务线各自维护 WASM 构建脚本，导致碎片化。
直接暴露底层 WASM API，业务代码难以维护。
忽略 ABI 兼容性，升级后导致线上实例化失败。

延伸追问：

如果两个业务线依赖不同版本的同一个 WASM 库，如何解决冲突？
WASM 模块的 npm 包如何兼顾浏览器和 Node.js 使用？

相关题目：

FB-49-EN-A-006 Emscripten 胶水代码
FB-49-FS-P-003 WASM 动态链接

参考资源：

口头回答版：

大型项目里我会把 WASM 按功能拆成独立包，比如 wasm-image、wasm-crypto，每个包有自己的 Rust/C 源码和构建脚本，输出 wasm、js 胶水、类型定义。再做一个统一的 JS 封装层，隐藏加载和内存管理，对外暴露 Promise API。加载策略上，关键模块预加载，非关键按需加载，大运算放 Worker。版本管理用 semver，ABI 大变更升主版本，CDN 加内容哈希和 SRI 校验，运行时还要检查 ABI 兼容性。

FB-49-SC-R-004：WebAssembly 在游戏引擎/WebGL 渲染管线中如何落地？

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、WebGL、性能 出现频率：中频 预计回答时长：15-20 分钟

题目描述：请设计一个基于 WebAssembly 和 WebGL 的浏览器端游戏引擎核心架构，说明 WASM 负责哪些计算，JS/WebGL 负责哪些工作，数据如何流转。

参考答案：

核心要点：WASM 负责游戏逻辑、物理模拟、寻路、动画计算等 CPU 密集型任务；JS/WebGL 负责资源加载、渲染提交、输入事件、音频和 UI；两者通过共享内存或结构化的渲染命令缓冲区协作。

详细解释：

职责划分：

模块	WASM	JS / WebGL
游戏逻辑	状态机、规则判定、AI	事件驱动、UI 反馈
物理	碰撞检测、刚体模拟	触发事件、同步视觉
动画	骨骼矩阵、插值计算	上传 uniform、绘制调用
寻路	网格/NavMesh 算法	接收路径结果、移动角色
渲染	生成 DrawCommand 列表	WebGL 执行绘制

数据流转：

text

Input Events → JS → WASM (更新游戏状态)
                       ↓
              WASM (生成 Transform/Matrix/DrawCommands)
                       ↓
              SharedArrayBuffer / TypedArray
                       ↓
              JS / WebGL (读取数据，调用 gl.draw*)

关键设计：
- 每帧 WASM 计算完成后，把变换矩阵、实例化数据写入共享内存。
- JS 读取这些数据，更新 WebGL uniform buffer 或 instance buffer。
- 尽量减少每帧 JS↔WASM 调用次数，采用“一帧一同步”。
优化手段：
- 多线程：WASM 使用 pthreads 在 Worker 中并行物理/AI 计算。
- SIMD：向量化矩阵运算和动画插值。
- GPU 实例化：减少 draw call。

代码示例（渲染命令缓冲区概念）：

javascript

// 每帧调用一次
function gameLoop(dt) {
  wasm.exports.update(dt); // WASM 更新状态和生成渲染数据
  const drawCount = wasm.exports.getDrawCount();
  const bufferPtr = wasm.exports.getRenderBufferPtr();

  // JS 读取 WASM 内存中的实例数据
  const instanceData = new Float32Array(
    wasm.exports.memory.buffer,
    bufferPtr,
    drawCount * 16
  );

  gl.bindBuffer(gl.ARRAY_BUFFER, instanceBuffer);
  gl.bufferSubData(gl.ARRAY_BUFFER, 0, instanceData);
  gl.drawArraysInstanced(gl.TRIANGLES, 0, 6, drawCount);
  requestAnimationFrame(gameLoop);
}

评分维度：

能清晰划分 WASM 与 WebGL/JS 职责（35%）
能设计合理的数据流转和同步机制（35%）
能提到多线程、SIMD、实例化等优化手段（30%）

常见错误：

让 WASM 直接做 WebGL API 调用（WASM 不能调用 WebGL）。
每帧多次小批量 JS↔WASM 通信，造成边界开销。
忽略 SharedArrayBuffer 所需的 COOP/COEP 跨域隔离。

延伸追问：

如果游戏状态很大，如何减少每帧从 WASM 到 JS 的数据拷贝？
多线程 WASM 如何与单线程的 WebGL context 协同？

相关题目：

FB-49-SC-R-001 前端图像处理系统
FB-49-SC-R-005 AI 推理中 WASM 与 WebGPU 协作

参考资源：

口头回答版：

浏览器端游戏引擎里，WASM 适合做 CPU 密集型计算，比如游戏逻辑、物理模拟、寻路、动画矩阵计算。JS 和 WebGL 负责输入事件、资源加载、渲染提交、音频和 UI。数据流是每帧 WASM 更新状态，把变换矩阵和渲染命令写到共享内存，JS 读出来上传到 WebGL 做绘制。关键是一帧同步一次，不要频繁跨边界调用。还可以用 pthreads 多线程和 SIMD 加速物理和动画。

FB-49-SC-R-005：AI/ML 模型前端推理方案中，WASM 与 WebGPU/WebGL 如何协作？

题型：场景设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、WebGPU、WebGL、性能 出现频率：高频 预计回答时长：15-20 分钟

题目描述：请设计一个浏览器端 AI 模型推理方案，说明 WebAssembly、WebGL、WebGPU 各自的角色，以及如何实现跨硬件能力的优雅降级。

参考答案：

核心要点：推理后端按性能优先级选择：WebGPU > WebGL > WASM（+ SIMD/多线程）。WASM 作为通用回退和模型图调度层，WebGPU/WebGL 负责大规模矩阵/张量计算的 GPU 加速。

详细解释：

后端能力分层：

后端	优势	劣势	适用场景
WebGPU	计算着色器、现代 GPU API、性能最高	浏览器支持较新	大模型、高吞吐
WebGL	兼容性好，可用 fragment shader 做 GPGPU	API 受限、精度/性能一般	中等模型、老浏览器
WASM+SIMD+Threads	通用、可预测、无 GPU 依赖	CPU 性能有限	小模型、CPU 回退
纯 JS	最简单	性能最低	极简模型、演示

整体架构：

text

Model Loader (JS)
      ↓
Runtime / Graph Scheduler (WASM or JS)
      ↓
Backend Dispatcher
      ├── WebGPU backend
      ├── WebGL backend
      └── WASM CPU backend

WASM 的角色：
- 模型解析和图调度：加载 ONNX/TensorFlow Lite 模型，构建计算图。
- 算子 fallback：某些算子在 GPU 上不支持时，用 WASM 实现。
- 数据预/后处理：tokenization、NMS、结果格式化。
- 通用回退：无 GPU 或 GPU 失败时执行完整推理。
降级策略：
- 运行时检测 navigator.gpu，优先启用 WebGPU。
- WebGPU 失败则回退到 WebGL。
- 都不支持则使用 WASM CPU backend。
- 提供明确的性能提示和加载状态。

最佳实践：

使用成熟的推理框架：ONNX Runtime Web、TensorFlow.js、Transformers.js。
对模型做量化（INT8/FP16）减小体积和内存。
预加载模型权重，避免首次推理等待。

评分维度：

能按 WebGPU/WebGL/WASM 分层说明角色（40%）
能设计合理的降级策略（30%）
能提到模型量化、预加载、算子 fallback 等工程实践（30%）

常见错误：

认为 WASM 推理一定比 WebGL/WebGPU 慢，忽略其作为 fallback 的价值。
让所有算子都跑在 WASM 上，未利用 GPU 加速。
忽略模型体积对首屏加载的影响。

延伸追问：

如果 WebGPU 后端某算子不支持，如何无缝切换到 WASM 算子？
前端推理如何保证模型权重不被恶意下载？

相关题目：

FB-49-SC-R-004 WASM 与 WebGL 游戏引擎
FB-49-PE-A-005 WASM 启动性能优化

参考资源：

口头回答版：

浏览器端 AI 推理我会按 WebGPU > WebGL > WASM 的优先级选后端。WebGPU 性能最高，适合大模型；WebGL 兼容性好；WASM 是通用 CPU 回退。WASM 除了做回退，还可以做模型解析、图调度、数据预处理、算子 fallback。架构上有一个 Backend Dispatcher，根据环境自动选后端。模型要做量化、预加载，给用户明确的降级提示。实际项目直接用 ONNX Runtime Web 或 TensorFlow.js 会更稳。

FB-49-SD-R-006：设计一个跨语言的“WASM 插件平台”，支持前端动态加载第三方扩展

题型：系统设计题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、安全、模块化 出现频率：中频 预计回答时长：20-30 分钟

题目描述：请设计一个前端应用中的 WASM 插件平台，支持第三方开发者用不同语言编写插件，运行时动态加载并安全执行。要求考虑插件接口、生命周期、安全隔离、错误处理和性能。

参考答案：

核心要点：插件平台需要定义稳定的 ABI/WIT 接口规范，提供插件注册、加载、运行、卸载生命周期；通过沙箱限制插件能力；使用 WASI Preview2/Component Model 提升跨语言互操作性；运行时捕获错误并隔离崩溃影响。

详细解释：

接口规范：
- 使用 WIT（WASM Interface Types）定义插件接口，支持复杂类型（字符串、列表、记录）。
- 定义标准生命周期钩子：init(config) -> Result、execute(input) -> Result、destroy()。
- 版本化 ABI，主应用和插件按 ABI 版本匹配。
插件生命周期：

text

Registry → Download → Validate → Instantiate → Sandbox Setup
                                          ↓
                             init → execute → destroy

安全隔离：
- 每个插件独立实例，独立的 Memory（或受控共享）。
- 通过能力模型限制 import：只暴露白名单 API（日志、有限存储、事件发布）。
- 设置执行超时、内存上限、CPU 配额。
- 对插件文件做 SRI 和签名验证。
- 不允许插件直接访问网络、DOM、本地存储。
错误处理：
- 插件 trap 时捕获 WebAssembly.RuntimeError，记录日志并隔离该插件。
- 通过 Result 类型返回业务错误，避免异常跨边界传播。
- 提供插件降级或卸载机制。
性能与工程：
- 插件按需加载，热更新时复用已编译 Module。
- 插件 marketplace 支持版本、依赖、权限声明。
- 提供 SDK 和本地调试工具。

代码示例（插件接口 WIT 示意）：

wit

package example:plugin;

interface host {
  log: func(msg: string);
  get-config: func() -> string;
}

interface plugin {
  init: func() -> result<string, string>;
  execute: func(input: string) -> result<string, string>;
}

评分维度：

能设计接口规范和生命周期（30%）
能说明安全隔离和能力模型（30%）
能考虑错误处理、性能、版本管理（25%）
能结合 WIT/Component Model 说明跨语言支持（15%）

常见错误：

插件接口设计过于随意，缺乏 ABI 版本管理。
给予插件过多权限，破坏安全沙箱。
插件崩溃未隔离，影响主应用。
忽略插件加载对首屏性能的影响。

延伸追问：

如何实现插件之间的通信，同时避免互相影响？
如果插件需要访问网络，你应该如何设计？

相关题目：

FB-49-SE-P-004 WASM 安全模型
FB-49-CP-P-007 WASI 是什么

参考资源：

口头回答版：

我会用 Component Model 和 WIT 定义插件接口，比如 init、execute、destroy 这些生命周期。每个插件独立实例，能力通过白名单 import 授予，限制内存、CPU、执行时间，还要做 SRI 和签名校验。插件出错时捕获 RuntimeError，记录日志并隔离，不影响主应用。插件从 registry 按需加载，可以复用编译好的 Module。如果插件需要网络或存储，必须通过宿主提供的受控 API，不能直接访问。

FB-49-CP-R-007：WebAssembly 在前端架构中的取舍：什么时候该用，什么时候不该用？

题型：综合开放题难度：⚫ 架构 岗位层级：架构师 面试知识域：49 WebAssembly 标签：WebAssembly、性能 出现频率：高频 预计回答时长：15-20 分钟

题目描述：作为前端架构师，请论述在项目中引入 WebAssembly 的决策框架：哪些情况值得引入，哪些情况应避免？需要考虑技术、团队、维护、安全哪些维度？

参考答案：

核心要点：引入 WASM 是权衡性能收益与工程成本的决策，应基于可量化的性能瓶颈、团队技能栈、长期维护成本和业务价值综合判断，避免为了技术噱头而引入。

详细解释：

值得引入 WASM 的情况：

维度	具体场景
性能瓶颈	已有 JS 实现成为 FPS/TTI/计算延迟瓶颈
算法复用	需要复用 C/C++/Rust 成熟库（图像、音视频、加密、AI）
稳定性	需要可预测的执行时间，避免 JS GC 抖动
跨平台	算法需要在 Web、Node.js、边缘侧复用
安全	需要沙箱隔离第三方代码或敏感算法

应避免或谨慎引入的情况：

维度	具体场景
简单业务	表单、列表、普通交互，无计算热点
DOM 密集	主要工作是 DOM 操作和样式计算
频繁通信	JS↔WASM 数据交换开销超过计算收益
团队储备不足	缺乏 C/Rust/WASM 调试经验，维护困难
包体积敏感	WASM 加胶水代码显著增加产物体积

决策框架：

text

1. 定义指标：FPS、TTI、计算耗时、包体积、维护成本
2. 基线测试：纯 JS 实现当前性能
3. 原型验证：用 WASM 实现最小可行版本
4. 成本评估：开发成本、构建复杂度、团队学习成本
5. 灰度上线：A/B 测试验证收益
6. 监控与回滚：线上性能、错误率、崩溃率

技术与非技术维度：
- 技术：性能、体积、启动时间、兼容性、调试难度。
- 团队：语言技能、工具链熟悉度、知识传承。
- 维护：构建流程、依赖更新、Bug 定位、文档。
- 安全：沙箱边界、供应链、代码审计。
- 业务：ROI、用户体验、竞品差异。

最佳实践：

用数据驱动决策，不做“为了 WASM 而 WASM”。
先做小范围试点，再决定是否扩大应用范围。
建立 WASM 模块的设计规范和代码审查流程。

评分维度：

能从技术、团队、维护、安全、业务多维度分析（40%）
能给出清晰的决策流程和量化指标（30%）
能结合实际案例说明取舍（30%）

常见错误：

仅因为 WASM 热门就引入，忽略实际收益。
低估 WASM 的调试和构建复杂度。
未做基线测试和 A/B 验证就全面替换。
忽略团队技能栈，导致维护困难。

延伸追问：

如果 CEO 要求把所有核心算法迁到 WASM，你如何说服他分阶段进行？
你如何看待 WASM 与 Native 客户端方案（Electron、Flutter）在性能上的取舍？

相关题目：

FB-49-PE-B-008 WASM 性能优势与适用场景
FB-49-SC-R-005 AI 推理中 WASM 与 WebGPU 协作

参考资源：

口头回答版：

引入 WASM 要看收益和成本的平衡。值得用的情况：有明确的性能瓶颈、需要复用 C/Rust 生态、执行时间要稳定、算法要跨平台、或者需要沙箱隔离第三方代码。不该用的情况：只是普通业务逻辑、主要操作 DOM、JS 和 WASM 频繁交换数据、团队没有相关经验、包体积敏感。我的决策流程是：先定指标，做基线测试，再做一个 WASM 原型验证，评估开发和维护成本，然后 A/B 上线，最后持续监控。不能为了技术热门而引入 WASM。

FB-49-CO-A-008：什么是 WebAssembly？它与 JavaScript 有什么关系？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、Wasm、JavaScript、浏览器 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请解释 WebAssembly 的概念，以及它与 JavaScript 的关系。

参考答案： WebAssembly（Wasm）是一种低级的类汇编语言，具有紧凑的二进制格式，可在现代浏览器中以接近原生的速度运行。

与 JavaScript 的关系：

互补而非替代
- JavaScript 适合 DOM 操作、业务逻辑、快速开发。
- WebAssembly 适合计算密集型任务，如音视频处理、游戏、加密。
同一运行时
- Wasm 与 JS 在同一个沙箱中运行。
- 共享内存、事件循环。
互操作
- JS 可以实例化 Wasm 模块，调用其导出的函数。
- Wasm 可以导入 JS 函数，实现与浏览器 API 交互。
性能
- Wasm 是静态类型、预编译的，执行效率更高。
- 启动和运行时性能优于解释执行的 JS。
语言无关
- 可用 C/C++、Rust、Go、AssemblyScript 等编译为 Wasm。

示例：

const wasm = await WebAssembly.instantiateStreaming(fetch('app.wasm'));
const result = wasm.instance.exports.add(1, 2);

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

WebAssembly 是二进制低级语言，在浏览器接近原生速度运行。它与 JS 互补，同运行时、可互操作，适合计算密集型任务，可用多种语言编译。

FB-49-CO-A-009：WebAssembly 的核心模块结构是什么？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、模块、结构、Memory、Table 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 模块的主要组成部分。

参考答案： WebAssembly 模块主要组成：

函数（Functions）
- 模块导出的可调用函数。
- 是 JS 与 Wasm 交互的主要方式。
线性内存（Linear Memory）
- 连续的 byte 数组，可通过 JS 和 Wasm 读写。
- 类似 C 语言的堆内存。
- 用 WebAssembly.Memory 创建。
表（Table）
- 存放函数引用的数组。
- 支持间接函数调用，如 C 语言函数指针。
全局变量（Globals）
- 模块级别的可变或不可变变量。
导入/导出（Imports/Exports）
- 导入：Wasm 从外部环境（通常是 JS）获取函数、内存、表、全局变量。
- 导出：Wasm 向外部环境暴露函数、内存、表、全局变量。
数据段/元素段（Data/Element Segments）
- 初始化内存和表的数据。

示例：

const importObject = {
  env: {
    memory: new WebAssembly.Memory({ initial: 256 }),
    abort: () => console.log('abort')
  }
};
const wasm = await WebAssembly.instantiate(bytes, importObject);

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 模块由函数、线性内存、表、全局变量、导入导出、数据段组成。线性内存是连续字节数组，表存函数引用，导入导出实现与 JS 互操作。

FB-49-CO-A-010：WebAssembly 的 Memory 是什么？如何与 JavaScript 共享数据？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、Memory、共享数据、JS 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 线性内存的概念，以及 JS 和 Wasm 如何通过 Memory 交换数据。

参考答案： WebAssembly Memory：

是一个可增长的 ArrayBuffer，称为线性内存。
Wasm 模块可以通过 load/store 指令读写内存。
JS 可以通过 memory.buffer 访问同一份内存。

共享数据方式：

JS 写数据到 Memory

const memory = new WebAssembly.Memory({ initial: 1 });
const bytes = new Uint8Array(memory.buffer);
const encoder = new TextEncoder();
const data = encoder.encode('hello');
bytes.set(data, 0);
wasm.instance.exports.processString(0);

Wasm 写数据到 Memory，JS 读取

const ptr = wasm.instance.exports.getResult();
const result = new Uint8Array(memory.buffer, ptr, length);
const str = new TextDecoder().decode(result);

Memory 增长
- Wasm 可通过 memory.grow(n) 增加页数。
- 增长后 JS 端的 memory.buffer 引用会失效，需要重新获取。

注意：

数据交换需要约定编码格式（如 UTF-8）。
注意内存对齐和边界。
多线程场景需用 SharedArrayBuffer。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm Memory 是可增长的 ArrayBuffer，JS 和 Wasm 可读写同一份内存。JS 通过 TextEncoder/Decoder 转换字符串，要注意 memory.grow 后 buffer 引用失效。

FB-49-CO-A-011：WebAssembly 支持哪些数据类型？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、数据类型、i32、f64 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 支持的基本数据类型。

参考答案： WebAssembly 基本数据类型：

类型	说明
i32	32 位整数
i64	64 位整数
f32	32 位浮点数
f64	64 位浮点数
v128	128 位 SIMD 向量（SIMD 提案）
funcref	函数引用
externref	外部引用（引用任意 JS 对象）

注意：

Wasm 不直接支持字符串、对象、数组等高级类型。
复杂数据需要通过线性内存传递，或使用 externref（Wasm GC/引用类型提案）。
多返回值、异常处理等通过提案逐步支持。

类型转换：

编译器（如 Emscripten、Rust wasm-bindgen）会处理高级类型到 Wasm 类型的映射。
手写 Wasm 时需要自己管理内存布局。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 基本类型有 i32、i64、f32、f64、v128、funcref、externref。不直接支持字符串对象数组，复杂数据通过内存传递或用 externref。

FB-49-CO-A-012：WebAssembly 的 instantiate 和 instantiateStreaming 有什么区别？

题型：概念题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、instantiate、加载、编译 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly.instantiate 和 WebAssembly.instantiateStreaming 的区别。

参考答案：区别：

特性	instantiate	instantiateStreaming
输入	ArrayBuffer 或 TypedArray	Response 对象（fetch 返回）
编译时机	先下载完整 buffer 再编译	边下载边编译
性能	需要等待完整下载	启动更快，可流式编译
使用场景	已有 buffer	从网络加载 Wasm 文件

示例：

// instantiate
const response = await fetch('app.wasm');
const bytes = await response.arrayBuffer();
const wasm = await WebAssembly.instantiate(bytes, importObject);

// instantiateStreaming
const response = fetch('app.wasm');
const wasm = await WebAssembly.instantiateStreaming(response, importObject);

建议：

网络加载 Wasm 时优先使用 instantiateStreaming。
需要缓存或处理 buffer 时用 instantiate。

注意：

服务端需正确设置 application/wasm MIME 类型，streaming 才能正常工作。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

instantiate 需要完整 ArrayBuffer 再编译，instantiateStreaming 可以边下载边编译，启动更快。网络加载优先用 streaming，服务端要设置正确 MIME 类型。

FB-49-CO-B-007：WebAssembly 的编译工具链有哪些？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：WebAssembly 标签：WebAssembly、工具链、Emscripten、Rust、AssemblyScript 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明常用的将高级语言编译为 WebAssembly 的工具链。

参考答案：常用 Wasm 编译工具链：

Emscripten
- 将 C/C++ 编译为 Wasm。
- 提供 POSIX 兼容层、SDL、OpenGL 支持。
- 适合移植大型 C/C++ 项目。
Rust + wasm-bindgen
- Rust 编译为 Wasm。
- wasm-bindgen 自动生成 JS 绑定，方便类型传递。
- wasm-pack 提供打包工具。
AssemblyScript
- TypeScript 语法编译为 Wasm。
- 适合前端开发者入门。
Go
- Go 1.11+ 支持编译为 Wasm。
- 但产物体积较大，启动较慢。
TinyGo
- Go 的轻量编译器，生成更小的 Wasm。
- 适合嵌入式和 Web。
Cheerp / CheerpX
- 将 C++ 编译为 Wasm 或 JS。
Javy / QuickJS
- 将 JS 编译为 Wasm，适合边缘计算。

选择建议：

高性能计算：Rust/C++。
前端团队：AssemblyScript。
已有 Go 项目：TinyGo。
大型游戏/仿真：Emscripten。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

常用工具链有 Emscripten（C/C++）、Rust+wasm-bindgen、AssemblyScript（TS 语法）、Go/TinyGo、Cheerp 等。高性能用 Rust/C++，前端团队用 AssemblyScript。

FB-49-CO-B-008：WebAssembly 适合哪些场景？不适合哪些场景？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：WebAssembly 标签：WebAssembly、场景、适用、不适用 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 适合和不适合的应用场景。

参考答案：适合场景：

计算密集型任务
- 图像/视频处理、音频分析、3D 渲染、科学计算。
游戏引擎
- Unity、Unreal 等可导出 Wasm。
- 浏览器中运行高性能游戏。
加密与安全
- 密码学算法、哈希计算、密钥派生。
编译器/解释器
- 在浏览器中运行其他语言，如 Pyodide（Python）、SQL 引擎。
代码移植
- 将现有 C/C++/Rust 代码库移植到 Web。
边缘计算
- Cloudflare Workers、Fastly Compute 支持 Wasm。

不适合场景：

大量 DOM 操作
- Wasm 访问 DOM 需通过 JS，成本高。
- 纯 UI 操作不如直接写 JS。
简单业务逻辑
- 如果 JS 足够快且易维护，没必要引入 Wasm。
极小体积要求
- Wasm 模块本身有体积，简单任务可能不如 JS 小。
强依赖浏览器 API
- 频繁调用浏览器 API 时，Wasm 与 JS 互操作开销明显。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 适合计算密集、游戏、加密、编译器、代码移植、边缘计算。不适合大量 DOM 操作、简单业务、极小体积、频繁浏览器 API 调用。

FB-49-CO-B-009：WebAssembly 的执行性能为什么比 JavaScript 高？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：WebAssembly 标签：WebAssembly、性能、AOT、JIT、JavaScript 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 性能优势的主要来源。

参考答案： Wasm 性能优势来源：

二进制格式
- 体积小，解析快。
- JS 需要词法分析、语法分析，Wasm 直接解码。
静态类型
- 类型信息在编译期确定。
- 不需要运行时类型推断和优化反优化循环。
接近机器码
- Wasm 指令是低级的、结构化的。
- 编译器可以更快生成高效机器码。
AOT 友好
- 浏览器可以一次性编译为机器码。
- JS JIT 需要预热和反优化，有运行时开销。
可预测的性能
- 没有 JS 中的隐藏类、垃圾回收停顿等问题。
- 适合实时性要求高的任务。
内存布局可控
- 线性内存连续，利于缓存命中。
- 适合数值计算和数据处理。

注意：

Wasm 不是处处比 JS 快。
频繁 JS/Wasm 互操作、DOM 操作会抵消优势。
实际性能需 benchmark 验证。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 性能高是因为二进制格式解析快、静态类型、接近机器码、AOT 编译、可预测性能、内存布局连续。但不是处处比 JS 快，频繁互操作会抵消优势。

FB-49-CO-B-010：WebAssembly 如何调用 JavaScript 函数？

题型：概念题难度：🟢 基础 岗位层级：初级 面试知识域：WebAssembly 标签：WebAssembly、JS、互操作、import 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 Wasm 模块如何调用 JavaScript 函数。

参考答案： Wasm 调用 JS 函数方式：

通过 importObject 导入
- 实例化 Wasm 时传入 importObject。
- Wasm 中声明 import，编译后通过模块名和字段名匹配。

示例：

const importObject = {
  env: {
    consoleLog: (n) => console.log('from wasm:', n),
    memory: new WebAssembly.Memory({ initial: 1 })
  }
};
const wasm = await WebAssembly.instantiateStreaming(fetch('app.wasm'), importObject);

对应 C/Rust 代码中声明：

extern void consoleLog(int n);

通过 Table 间接调用
- 函数表存放函数引用，支持动态函数指针调用。
通过 JS 导出函数后传入
- JS 把函数作为参数传给 Wasm 导出的函数。
wasm-bindgen / Emscripten
- 自动生成绑定代码，简化互操作。

注意事项：

导入函数的签名必须和 Wasm 中声明一致。
调用频繁时要注意开销。
异步操作需特别处理。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 通过 importObject 导入 JS 函数，实例化时传入，Wasm 中用 extern 声明。也可用函数表间接调用。实际开发用 wasm-bindgen 或 Emscripten 自动生成绑定。

FB-49-CP-P-008：WebAssembly 如何实现多线程？

题型：综合开放题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、多线程、SharedArrayBuffer、Worker 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 在浏览器中实现多线程的方案。

参考答案： Wasm 多线程方案：

Web Workers
- 每个 Worker 中加载独立的 Wasm 实例。
- 通过 SharedArrayBuffer 共享内存。
SharedArrayBuffer
- 创建 Wasm Memory 时使用 shared: true。
- 多个 Worker 中的 Wasm 实例共享同一份内存。
- 需要原子操作（Atomics）保证线程安全。
Wasm 线程提案
- 支持在 Wasm 内部创建线程（pthread）。
- Emscripten 的 -s USE_PTHREADS=1 可启用。
- Rust 的 wasm-bindgen-rayon 支持 rayon 并行。
浏览器支持
- 需要 COOP/COEP 响应头启用 SharedArrayBuffer。
- 部分浏览器和环境有安全限制。

示例：

const memory = new WebAssembly.Memory({
  initial: 1,
  maximum: 4,
  shared: true
});

注意事项：

多线程编程复杂，需注意数据竞争、死锁。
线程创建和销毁有开销，适合计算密集型任务。
移动端 Web 对 SharedArrayBuffer 支持有限。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 多线程通过 Web Workers 加载独立实例，用 SharedArrayBuffer 共享内存，Wasm 线程提案支持 pthread。要启用 COOP/COEP 头，注意数据竞争和移动端支持。

FB-49-CP-P-009：WebAssembly 如何实现异常处理？

题型：综合开放题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、异常、Exception Handling、错误 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 中的异常处理机制及其实现方式。

参考答案： Wasm 异常处理：

早期方案：返回错误码
- C 风格：函数返回错误码，通过内存传递错误信息。
- 简单但破坏代码结构。
Exception Handling 提案
- Wasm 原生支持 try/catch/throw 指令。
- 浏览器逐步支持。
- 编译器可映射高级语言异常。
Emscripten 方案
- 使用 -s DISABLE_EXCEPTION_CATCHING=0 启用 C++ 异常。
- 有性能开销，默认关闭。
Rust 方案
- Rust panic 在 Wasm 中默认 abort。
- 可通过 console_error_panic_hook 输出错误信息。
JS 侧捕获
- 调用 Wasm 导出函数时用 try/catch。
- 但 Wasm 内部异常不一定能正确抛出。
错误码 + Result 类型
- Rust 推荐用 Result 返回错误。
- 避免异常跨边界传播。

建议：

跨语言边界尽量用错误码或 Result 传递错误。
在 Wasm 内部可使用语言原生异常机制。
注意异常处理提案的浏览器兼容性。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 异常处理早期用错误码，现在有 Exception Handling 提案。Emscripten 和 Rust 各有方案。跨语言边界建议用错误码或 Result，注意兼容性。

FB-49-CP-P-010：WebAssembly 的 SIMD 是什么？有什么应用？

题型：综合开放题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、SIMD、向量、性能 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly SIMD 的概念和应用场景。

参考答案： WebAssembly SIMD：

SIMD（Single Instruction, Multiple Data）即单指令多数据。
Wasm SIMD 提案引入 128 位向量类型 v128 和相关指令。
一条指令可同时处理多个数据，提升并行计算性能。

应用场景：

图像处理
- 像素级操作，如滤镜、缩放、颜色转换。
音视频编解码
- 音频采样处理、视频帧处理。
机器学习
- 矩阵运算、向量点积。
游戏物理
- 向量运算、碰撞检测。
密码学
- 某些加密算法可 SIMD 加速。

使用方式：

编译器自动向量化（如 Rust -C target-feature=+simd128）。
手写 SIMD 指令（较少见）。

浏览器支持：

现代浏览器已支持 Wasm SIMD。
使用前应做特性检测。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm SIMD 是单指令多数据，用 128 位向量提升并行计算。应用于图像处理、音视频、机器学习、游戏物理、密码学。现代浏览器已支持，使用前要检测。

FB-49-CP-P-011：WebAssembly 与 WASI 有什么关系？

题型：综合开放题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、WASI、系统接口、WebAssembly System Interface 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WASI 的概念及其与 WebAssembly 的关系。

参考答案： WASI（WebAssembly System Interface）：

是 WebAssembly 访问操作系统能力的标准接口。
让 Wasm 不仅在浏览器运行，还能在服务器、边缘设备等环境运行。
提供文件系统、网络、时钟、随机数等系统能力。

关系：

Wasm 是执行格式。
WASI 是 Wasm 与宿主环境交互的接口规范。

WASI 特点：

可移植性
- 一次编译，到处运行（只要有 WASI runtime）。
安全性
- 基于能力的安全模型（capability-based security）。
- 程序只能访问显式授予的资源。
模块化
- 标准化系统调用接口。

常见 WASI Runtime：

Wasmtime（Rust）
Wasmer
WasmEdge
Node.js（实验性）

应用场景：

边缘计算、微服务、插件系统、沙箱执行。

示例：

wasmtime app.wasm

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

WASI 是 Wasm 访问操作系统能力的标准接口，让 Wasm 可在浏览器外运行。特点是可移植、安全、模块化。常见 runtime 有 Wasmtime、Wasmer、WasmEdge。

FB-49-EN-A-007：如何在 Web 项目中集成 Rust 编译的 WebAssembly？

题型：工程化题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：Rust、WebAssembly、wasm-bindgen、集成 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明将 Rust 代码编译为 Wasm 并在前端项目中使用的流程。

参考答案： Rust + Wasm 集成流程：

安装工具
- Rust toolchain
- wasm-pack：cargo install wasm-pack
创建 Rust 项目
sh
```
cargo new --lib my-wasm
```
1

配置 Cargo.toml

toml

[lib]
crate-type = ["cdylib"]

[dependencies]
wasm-bindgen = "0.2"

编写 Rust 代码

rust

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add(a: i32, b: i32) -> i32 {
    a + b
}

编译为 Wasm
sh
```
wasm-pack build --target web
```
1

在前端使用

import init, { add } from './pkg/my_wasm.js';
await init();
console.log(add(1, 2));

打包工具配置
- Webpack/Vite/Rollup 配置 wasm 加载。
- wasm-pack 生成的 JS 包装器通常可直接使用。

最佳实践：

复杂类型用 wasm-bindgen 自动生成绑定。
大数据通过 Memory 传递。
初始化异步完成后再调用函数。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Rust 到 Wasm 用 wasm-pack，配置 crate-type 为 cdylib，写 wasm_bindgen 导出函数，编译后用 init 初始化再调用。大数据通过 Memory 传递。

FB-49-EN-A-008：Emscripten 编译 WebAssembly 时常用哪些编译选项？

题型：工程化题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：Emscripten、编译选项、WebAssembly、C++ 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明使用 Emscripten 将 C/C++ 编译为 Wasm 时的常用选项。

参考答案： Emscripten 常用编译选项：

输出格式
- -o app.html：生成 HTML + JS + Wasm。
- -o app.js：生成 JS + Wasm。
- -o app.wasm：仅 Wasm。
优化级别
- -O0：无优化，调试。
- -O2：常规优化。
- -O3：激进优化。
- -Os：优化体积。
- -Oz：极致优化体积。
模块化输出
- -s MODULARIZE=1：生成可实例化的模块。
- -s EXPORT_NAME='MyModule'：指定模块名。
导出函数
- -s EXPORTED_FUNCTIONS='["_add", "_sub"]'：导出 C 函数。
- -s EXPORTED_RUNTIME_METHODS='["ccall", "cwrap"]'：导出 JS 运行时方法。
内存设置
- -s INITIAL_MEMORY=64MB
- -s MAXIMUM_MEMORY=256MB
- -s ALLOW_MEMORY_GROWTH=1
其他常用
- -s USE_PTHREADS=1：启用多线程。
- -s DISABLE_EXCEPTION_CATCHING=0：启用异常。
- -s FILESYSTEM=0：禁用虚拟文件系统，减小体积。

示例：

emcc add.c -o add.js -O3 -s MODULARIZE=1 -s EXPORTED_FUNCTIONS='["_add"]' -s EXPORTED_RUNTIME_METHODS='["ccall"]' -s ALLOW_MEMORY_GROWTH=1

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Emscripten 常用选项包括输出格式、优化级别、MODULARIZE、EXPORTED_FUNCTIONS、内存设置、多线程、异常、文件系统等。根据需求组合使用。

FB-49-EN-A-009：WebAssembly 在前端工程化中如何加载和打包？

题型：工程化题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、工程化、Webpack、Vite、加载 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明前端项目中如何加载和打包 Wasm 文件。

参考答案：前端 Wasm 加载和打包：

直接 fetch 加载

const response = fetch('app.wasm');
const wasm = await WebAssembly.instantiateStreaming(response, importObject);

Webpack
- Webpack 4+ 支持 .wasm 文件。
- 需配置 experiments.asyncWebAssembly 或 experiments.syncWebAssembly。
Vite
- Vite 支持直接 import .wasm 文件。
- import init from './app.wasm?init'。
wasm-pack
- 生成 JS 包装器，可直接 import。
- 适合 Rust 项目。
Emscripten 生成 JS
- 直接引入生成的 JS 文件。
- JS 会负责加载对应 Wasm。
MIME 类型
- 服务器需设置 application/wasm。
- 否则 streaming 加载会失败。
懒加载
- 大 Wasm 模块可异步 import，减少首屏负担。
缓存
- 利用浏览器缓存，配合版本号或 hash。

示例（Vite）：

import init from './calc.wasm?init';
const wasm = await init();
console.log(wasm.exports.add(1, 2));

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

前端 Wasm 可直接 fetch、Webpack/Vite 打包、wasm-pack 生成 JS 包装器、Emscripten 生成 JS。注意服务器 MIME 类型，大模块懒加载，做好缓存。

FB-49-FS-P-006：WebAssembly 的运行时生命周期是怎样的？

题型：框架原理题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、生命周期、编译、实例化 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 从源码到运行的完整生命周期。

参考答案： Wasm 运行时生命周期：

源码编写
- 用 C/C++/Rust/AssemblyScript 等高级语言编写。
编译为 Wasm 二进制
- 使用工具链编译为 .wasm 文件。
- 可能同时生成 JS 胶水代码。
加载到浏览器
- 通过 fetch 或 import 获取 Wasm 文件。
编译（Compile）
- WebAssembly.compile 或 instantiate 内部编译。
- 将 Wasm 二进制转换为浏览器内部表示。
实例化（Instantiate）
- 提供 importObject（内存、函数、全局变量等）。
- 创建 Wasm 模块实例，分配资源。
执行
- 调用实例导出的函数。
- Wasm 读写线性内存，与 JS 互操作。
销毁
- 实例不再被引用时由 GC 回收。
- 线性内存由 JS 控制释放。

注意：

编译后的 Module 可多次实例化。
实例化是同步还是异步取决于 API。
Worker 中也可运行 Wasm。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 生命周期：源码 → 编译为 wasm → 加载 → 编译 → 实例化 → 执行 → 销毁。Module 可多次实例化，实例化需 importObject。

FB-49-FS-P-007：WebAssembly 的 GC 提案是什么？有什么意义？

题型：框架原理题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、GC、垃圾回收、提案 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly GC 提案的内容和意义。

参考答案： Wasm GC 提案：

为 WebAssembly 添加垃圾回收和托管对象支持。
允许 Wasm 直接表示对象、数组、字符串等高级类型。
不再需要完全依赖线性内存和手动内存管理。

意义：

简化编译
- 高级语言编译到 Wasm 更容易。
- 如 Java、Kotlin、Dart 等可更高效地 targeting Wasm。
互操作性
- Wasm 对象可直接与 JS 对象交互。
- 减少序列化和内存拷贝。
性能
- 托管内存由浏览器统一 GC，可能更高效。
- 减少线性内存管理开销。
安全性
- 避免手动内存管理导致的漏洞。

状态：

Wasm GC 提案已进入提案流程后期。
部分浏览器开始支持。

影响：

未来更多高级语言可直接编译为 Wasm。
Wasm 与 JS 的边界会更模糊。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm GC 提案增加垃圾回收和托管对象，让 Wasm 直接表示对象数组字符串。意义是简化高级语言编译、提升互操作和性能、增强安全。部分浏览器已开始支持。

FB-49-FS-P-008：WebAssembly 的 Component Model 是什么？

题型：框架原理题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、Component Model、组件、互操作 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly Component Model 的概念和目标。

参考答案： WebAssembly Component Model：

是 WebAssembly 的组件化标准提案。
目标是在 Wasm 模块之上定义可组合、可互操作的组件。
类似软件组件的“USB 接口”。

核心概念：

Interface Types
- 定义组件间交互的高级类型（字符串、列表、记录等）。
- 自动处理跨语言类型转换。
组件（Component）
- 一个或多个 Wasm 模块的封装。
- 明确定义 import 和 export 接口。
组合（Composition）
- 不同语言编译的组件可以组合在一起。
- 例如 Rust 组件调用 Go 组件。

目标：

跨语言复用。
简化插件系统。
标准化 WASI 应用接口。
促进云原生和边缘计算生态。

FB-49-FS-P-009：WebAssembly 在边缘计算中的应用有哪些？

题型：框架原理题难度：🔴 深入 岗位层级：专家 面试知识域：WebAssembly 标签：WebAssembly、边缘计算、Serverless、安全 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 WebAssembly 在边缘计算场景中的优势和应用。

参考答案： Wasm 在边缘计算中的应用：

边缘 Serverless
- Cloudflare Workers、Fastly Compute、AWS Lambda 支持 Wasm。
- 冷启动快，资源占用低。
插件系统
- 在网关、代理中运行动态加载的 Wasm 插件。
- 如 Envoy Wasm 扩展。
安全沙箱
- Wasm 运行时有强隔离能力。
- 适合执行不可信代码。
轻量函数
- 函数体积小，启动毫秒级。
- 适合高并发、低延迟场景。
跨语言运行时
- 不同语言编写的业务逻辑统一在 Wasm 运行时执行。
IoT 和嵌入式
- 小体积、可移植，适合资源受限设备。

优势：

启动快、体积小。
安全隔离。
可移植。
多语言支持。

挑战：

生态和工具链仍在完善。
调试和可观测性相对复杂。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 在边缘计算用于 Serverless、插件系统、安全沙箱、轻量函数、IoT。优势是启动快、体积小、安全隔离、可移植、多语言。

FB-49-PE-A-006：WebAssembly 模块体积如何优化？

题型：性能优化题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、体积优化、wasm-opt、压缩 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明减小 WebAssembly 模块体积的方法。

参考答案： Wasm 体积优化：

编译优化
- 使用 -Os、-Oz 优化体积。
- Rust 使用 opt-level = 'z' 和 lto = true。
wasm-opt
- Binaryen 提供的优化工具。
- wasm-opt -Oz app.wasm -o app.opt.wasm。
移除未使用代码
- 只导出需要的函数。
- 使用 dead code elimination。
禁用不需要的运行时
- Emscripten 中 FILESYSTEM=0。
- 减少胶水代码体积。
压缩传输
- 服务器开启 gzip/brotli。
- Wasm 二进制可压缩率高。
按需加载
- 大模块拆分为多个小模块。
- 使用时动态加载。
避免过度泛型
- Rust 中过度泛型会生成大量代码。
使用 TinyGo
- Go 项目用 TinyGo 生成更小体积。
分析工具
- wasm-strip、twiggy 分析体积分布。

示例：

wasm-opt -Oz input.wasm -o output.wasm

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 体积优化用编译优化、wasm-opt、移除未用代码、禁用不需要的运行时、gzip/brotli 压缩、按需加载、避免过度泛型、TinyGo。用 wasm-strip/twiggy 分析。

FB-49-PE-A-007：WebAssembly 与 JavaScript 互操作的性能瓶颈是什么？

题型：性能优化题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、JS、互操作、性能瓶颈 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明 Wasm 与 JS 频繁互操作时的性能瓶颈及优化方法。

参考答案：互操作性能瓶颈：

调用开销
- 每次跨边界调用都有一定开销。
- 高频小调用比批量调用慢。
数据序列化
- 字符串、对象等复杂数据需要编码/解码。
- 通过 Memory 传递可减少拷贝，但需手动管理。
类型转换
- JS 动态类型与 Wasm 静态类型转换有成本。
内存视图失效
- Memory grow 后 JS 的 TypedArray 视图失效，需重新创建。

优化方法：

批量处理
- 一次调用处理大量数据，减少边界穿越次数。
共享内存
- 大数据直接通过 Memory 传递指针。
减少字符串传递
- 尽量传递数字、索引，字符串必要时编码。
合并函数
- 把多个小函数合并为一个粗粒度函数。
使用 wasm-bindgen
- 自动生成高效绑定，减少手动开销。
预分配内存
- 避免运行中频繁 memory.grow。
避免 JS 回调循环
- 不要在 Wasm 循环中频繁回调 JS。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 与 JS 互操作瓶颈是调用开销、数据序列化、类型转换、内存视图失效。优化要批量处理、共享内存、减少字符串传递、合并函数、用 wasm-bindgen、预分配内存、避免循环回调 JS。

FB-49-PE-A-008：WebAssembly 启动性能如何优化？

题型：性能优化题难度：🟡 进阶 岗位层级：高级 面试知识域：WebAssembly 标签：WebAssembly、启动、性能、编译 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请说明优化 WebAssembly 首次加载和启动性能的方法。

参考答案： Wasm 启动性能优化：

使用 instantiateStreaming
- 边下载边编译，减少等待时间。
模块缓存
- 使用 WebAssembly.Module 缓存编译结果。
- IndexedDB 可持久化缓存。
减小模块体积
- 体积越小，下载和编译越快。
延迟加载
- 非首屏功能模块延迟实例化。
预编译
- 使用 WebAssembly.compile 提前编译。
- 需要时再 instantiate。
Worker 中编译
- 大模块在 Worker 中编译，避免阻塞主线程。
分片加载
- 大模块拆小，按需加载。
服务端优化
- 启用 gzip/brotli、HTTP/2、CDN。
Baseline compiler
- 浏览器先用 baseline 编译快速启动，再用 optimizing compiler 优化。
- 无法直接控制，但了解有助于设计。
预取/预加载
- 用 <link rel="preload"> 提前获取 wasm 文件。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 启动优化用 instantiateStreaming、Module 缓存、减小体积、延迟加载、预编译、Worker 编译、分片、服务端压缩、预取。

FB-49-SC-R-006：设计一个基于 WebAssembly 的浏览器端图片编辑器架构。

题型：场景设计题难度：🔵 架构 岗位层级：架构师 面试知识域：WebAssembly 标签：WebAssembly、图片编辑、架构、浏览器 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请设计一个浏览器端图片编辑器，使用 WebAssembly 处理图像算法。

参考答案：浏览器端 Wasm 图片编辑器架构：

UI 层（JS/React/Vue）
- 画布展示、工具栏、图层面板、历史记录。
- 用户交互和状态管理。
Wasm 核心层（C++/Rust）
- 图像解码、滤镜算法、变换、合成。
- 直接操作像素数据，性能高。
数据流
- JS 读取图片文件 → 传入 Wasm Memory。
- Wasm 处理像素 → 返回处理后的像素或指针。
- JS 将结果渲染到 Canvas。
Canvas 渲染
- 使用 OffscreenCanvas 或 WorkerCanvas 在 Worker 中渲染。
- 大图片避免阻塞主线程。
历史记录
- 保存操作参数，支持撤销重做。
- 可保存像素快照或参数化命令。
滤镜系统
- 滤镜参数由 UI 传递到 Wasm。
- Wasm 应用矩阵变换、卷积、色彩映射。
多线程
- 图片分块处理，使用 Wasm 多线程或 Worker。
格式支持
- 集成 libpng、libjpeg、libwebp 等解码库。
- 输出多种格式。
性能监控
- 测量处理耗时，优化慢滤镜。
内存管理
- 及时释放 Wasm 中分配的内存。
- 避免大图片导致 OOM。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

架构分 UI 层、Wasm 核心层、Canvas 渲染。图片数据通过 Memory 传给 Wasm 处理，再回 Canvas。支持历史记录、滤镜参数化、多线程、多格式、性能监控和内存管理。

FB-49-SC-R-007：WebAssembly 未来可能如何改变前端开发？

题型：场景设计题难度：🔵 架构 岗位层级：架构师 面试知识域：WebAssembly 标签：WebAssembly、未来、前端、趋势 出现频率：高频 预计回答时长：5-8 分钟

题目描述：请谈谈 WebAssembly 对未来前端开发可能带来的影响。

参考答案： Wasm 对前端开发的影响：

性能边界扩展
- 浏览器能运行更复杂的应用，如视频编辑、CAD、游戏。
语言多样性
- 前端不再只能用 JavaScript。
- Rust、C++、Go、Python（Pyodide）等可运行在浏览器。
代码复用
- 现有 C/C++/Rust 代码库可直接用于 Web。
- 降低跨平台成本。
新应用形态
- 云端 IDE、浏览器端数据库、复杂仿真工具。
边缘与前端融合
- 同一份 Wasm 代码可运行在浏览器和边缘节点。
组件化生态
- Component Model 成熟后，跨语言组件市场可能出现。
前端职责变化
- 前端需要理解更多语言、编译、内存管理知识。
- 与底层开发界限模糊。
挑战
- 调试、可观测性、安全、包体积仍需关注。
- 不是所有场景都适合 Wasm。

总结：

Wasm 不会替代 JS，但会极大扩展 Web 平台能力。
前端开发者应关注并适时掌握。

评分维度：

能准确理解问题并给出结构化回答（40%）
能结合实际案例或数据说明（30%）
能体现业务思维与技术落地的结合（30%）

常见错误：

回答过于空泛，缺乏具体做法。
只谈技术实现，忽略业务目标和约束。
没有考虑风险和可执行性。

口头回答版：

Wasm 会扩展浏览器性能边界，带来多语言、代码复用、新应用形态、边缘融合、组件化。前端需学习更多底层知识，但不会替代 JS。

WebAssembly 面试题 ​

目录 ​

基础题（8 道） ​

FB-49-CO-B-001：什么是 WebAssembly？它和 JavaScript 的关系是什么？ ​

FB-49-CO-B-002：WebAssembly 有哪些核心特点？ ​

FB-49-CO-B-003：WASM 的编译流程是怎样的？WAT 和 WASM 是什么关系？ ​

FB-49-CO-B-004：如何在浏览器中加载和实例化一个 WASM 模块？ ​

FB-49-CO-B-005：WASM 模块实例中的 exports 和 imports 是什么？ ​

FB-49-CO-B-006：WebAssembly 支持哪些基本数据类型？ ​

FB-49-CA-B-007：下面代码的输出是什么？为什么？ ​

FB-49-PE-B-008：WebAssembly 在哪些场景有性能优势？哪些场景不适合？ ​

进阶题（8 道） ​

FB-49-CO-A-001：WebAssembly 的线性内存（Linear Memory）是如何工作的？ ​

FB-49-CO-A-002：WebAssembly 的 Table 是什么？有什么作用？ ​

FB-49-CD-A-003：手写 JS 调用 WASM 导出函数并传递字符串的示例 ​

FB-49-CO-A-004：WASM 中的全局变量（Global）是什么？如何与 JS 共享？ ​

FB-49-PE-A-005：如何优化 WebAssembly 的启动时间和运行时性能？ ​

FB-49-EN-A-006：Emscripten 是什么？它的胶水代码（glue code）做了什么？ ​

FB-49-CO-A-007：AssemblyScript 和 Rust 在 WASM 开发中的定位与差异 ​

FB-49-CA-A-008：下面 WASM 内存操作代码会发生什么？如何排查？ ​

深入题（7 道） ​

FB-49-FS-P-001：WebAssembly 模块的二进制格式结构是怎样的？ ​

FB-49-FS-P-002：WebAssembly 的验证（Validation）和实例化（Instantiation）过程是怎样的？ ​

FB-49-FS-P-003：WebAssembly 如何实现动态链接和模块间调用？ ​

FB-49-SE-P-004：WebAssembly 的安全模型与沙箱机制是怎样的？ ​

FB-49-FS-P-005：WebAssembly 的内存管理与垃圾回收机制是怎样的？ ​

FB-49-EN-P-006：如何调试 WebAssembly？有哪些工具和方法？ ​

FB-49-CP-P-007：WASI 是什么？它和 WebAssembly 有什么关系？ ​

架构题（32 道） ​

FB-49-SC-R-001：如何设计一个前端图像处理系统，引入 WebAssembly 进行计算加速？ ​

FB-49-SC-R-002：设计一个浏览器端视频编解码方案，WebAssembly 扮演什么角色？ ​

FB-49-SC-R-003：如何在大型前端项目中组织 WASM 模块的构建、加载与版本管理？ ​

FB-49-SC-R-004：WebAssembly 在游戏引擎/WebGL 渲染管线中如何落地？ ​

FB-49-SC-R-005：AI/ML 模型前端推理方案中，WASM 与 WebGPU/WebGL 如何协作？ ​

FB-49-SD-R-006：设计一个跨语言的“WASM 插件平台”，支持前端动态加载第三方扩展 ​

FB-49-CP-R-007：WebAssembly 在前端架构中的取舍：什么时候该用，什么时候不该用？ ​

FB-49-CO-A-008：什么是 WebAssembly？它与 JavaScript 有什么关系？ ​

FB-49-CO-A-009：WebAssembly 的核心模块结构是什么？ ​

FB-49-CO-A-010：WebAssembly 的 Memory 是什么？如何与 JavaScript 共享数据？ ​

FB-49-CO-A-011：WebAssembly 支持哪些数据类型？ ​

FB-49-CO-A-012：WebAssembly 的 instantiate 和 instantiateStreaming 有什么区别？ ​

FB-49-CO-B-007：WebAssembly 的编译工具链有哪些？ ​

FB-49-CO-B-008：WebAssembly 适合哪些场景？不适合哪些场景？ ​

FB-49-CO-B-009：WebAssembly 的执行性能为什么比 JavaScript 高？ ​

FB-49-CO-B-010：WebAssembly 如何调用 JavaScript 函数？ ​

FB-49-CP-P-008：WebAssembly 如何实现多线程？ ​

FB-49-CP-P-009：WebAssembly 如何实现异常处理？ ​

FB-49-CP-P-010：WebAssembly 的 SIMD 是什么？有什么应用？ ​

FB-49-CP-P-011：WebAssembly 与 WASI 有什么关系？ ​

FB-49-EN-A-007：如何在 Web 项目中集成 Rust 编译的 WebAssembly？ ​

FB-49-EN-A-008：Emscripten 编译 WebAssembly 时常用哪些编译选项？ ​

FB-49-EN-A-009：WebAssembly 在前端工程化中如何加载和打包？ ​

FB-49-FS-P-006：WebAssembly 的运行时生命周期是怎样的？ ​

FB-49-FS-P-007：WebAssembly 的 GC 提案是什么？有什么意义？ ​

FB-49-FS-P-008：WebAssembly 的 Component Model 是什么？ ​

FB-49-FS-P-009：WebAssembly 在边缘计算中的应用有哪些？ ​

FB-49-PE-A-006：WebAssembly 模块体积如何优化？ ​

FB-49-PE-A-007：WebAssembly 与 JavaScript 互操作的性能瓶颈是什么？ ​

FB-49-PE-A-008：WebAssembly 启动性能如何优化？ ​

FB-49-SC-R-006：设计一个基于 WebAssembly 的浏览器端图片编辑器架构。 ​

FB-49-SC-R-007：WebAssembly 未来可能如何改变前端开发？ ​

WebAssembly 面试题

目录

基础题（8 道）

FB-49-CO-B-001：什么是 WebAssembly？它和 JavaScript 的关系是什么？

FB-49-CO-B-002：WebAssembly 有哪些核心特点？

FB-49-CO-B-003：WASM 的编译流程是怎样的？WAT 和 WASM 是什么关系？

FB-49-CO-B-004：如何在浏览器中加载和实例化一个 WASM 模块？

FB-49-CO-B-005：WASM 模块实例中的 exports 和 imports 是什么？

FB-49-CO-B-006：WebAssembly 支持哪些基本数据类型？

FB-49-CA-B-007：下面代码的输出是什么？为什么？

FB-49-PE-B-008：WebAssembly 在哪些场景有性能优势？哪些场景不适合？

进阶题（8 道）

FB-49-CO-A-001：WebAssembly 的线性内存（Linear Memory）是如何工作的？

FB-49-CO-A-002：WebAssembly 的 Table 是什么？有什么作用？

FB-49-CD-A-003：手写 JS 调用 WASM 导出函数并传递字符串的示例

FB-49-CO-A-004：WASM 中的全局变量（Global）是什么？如何与 JS 共享？

FB-49-PE-A-005：如何优化 WebAssembly 的启动时间和运行时性能？

FB-49-EN-A-006：Emscripten 是什么？它的胶水代码（glue code）做了什么？

FB-49-CO-A-007：AssemblyScript 和 Rust 在 WASM 开发中的定位与差异

FB-49-CA-A-008：下面 WASM 内存操作代码会发生什么？如何排查？

深入题（7 道）

FB-49-FS-P-001：WebAssembly 模块的二进制格式结构是怎样的？

FB-49-FS-P-002：WebAssembly 的验证（Validation）和实例化（Instantiation）过程是怎样的？

FB-49-FS-P-003：WebAssembly 如何实现动态链接和模块间调用？

FB-49-SE-P-004：WebAssembly 的安全模型与沙箱机制是怎样的？

FB-49-FS-P-005：WebAssembly 的内存管理与垃圾回收机制是怎样的？

FB-49-EN-P-006：如何调试 WebAssembly？有哪些工具和方法？

FB-49-CP-P-007：WASI 是什么？它和 WebAssembly 有什么关系？

架构题（32 道）

FB-49-SC-R-001：如何设计一个前端图像处理系统，引入 WebAssembly 进行计算加速？

FB-49-SC-R-002：设计一个浏览器端视频编解码方案，WebAssembly 扮演什么角色？

FB-49-SC-R-003：如何在大型前端项目中组织 WASM 模块的构建、加载与版本管理？

FB-49-SC-R-004：WebAssembly 在游戏引擎/WebGL 渲染管线中如何落地？

FB-49-SC-R-005：AI/ML 模型前端推理方案中，WASM 与 WebGPU/WebGL 如何协作？

FB-49-SD-R-006：设计一个跨语言的“WASM 插件平台”，支持前端动态加载第三方扩展

FB-49-CP-R-007：WebAssembly 在前端架构中的取舍：什么时候该用，什么时候不该用？

FB-49-CO-A-008：什么是 WebAssembly？它与 JavaScript 有什么关系？

FB-49-CO-A-009：WebAssembly 的核心模块结构是什么？

FB-49-CO-A-010：WebAssembly 的 Memory 是什么？如何与 JavaScript 共享数据？

FB-49-CO-A-011：WebAssembly 支持哪些数据类型？

FB-49-CO-A-012：WebAssembly 的 instantiate 和 instantiateStreaming 有什么区别？

FB-49-CO-B-007：WebAssembly 的编译工具链有哪些？

FB-49-CO-B-008：WebAssembly 适合哪些场景？不适合哪些场景？

FB-49-CO-B-009：WebAssembly 的执行性能为什么比 JavaScript 高？

FB-49-CO-B-010：WebAssembly 如何调用 JavaScript 函数？

FB-49-CP-P-008：WebAssembly 如何实现多线程？

FB-49-CP-P-009：WebAssembly 如何实现异常处理？

FB-49-CP-P-010：WebAssembly 的 SIMD 是什么？有什么应用？

FB-49-CP-P-011：WebAssembly 与 WASI 有什么关系？

FB-49-EN-A-007：如何在 Web 项目中集成 Rust 编译的 WebAssembly？

FB-49-EN-A-008：Emscripten 编译 WebAssembly 时常用哪些编译选项？

FB-49-EN-A-009：WebAssembly 在前端工程化中如何加载和打包？

FB-49-FS-P-006：WebAssembly 的运行时生命周期是怎样的？

FB-49-FS-P-007：WebAssembly 的 GC 提案是什么？有什么意义？

FB-49-FS-P-008：WebAssembly 的 Component Model 是什么？

FB-49-FS-P-009：WebAssembly 在边缘计算中的应用有哪些？

FB-49-PE-A-006：WebAssembly 模块体积如何优化？

FB-49-PE-A-007：WebAssembly 与 JavaScript 互操作的性能瓶颈是什么？

FB-49-PE-A-008：WebAssembly 启动性能如何优化？

FB-49-SC-R-006：设计一个基于 WebAssembly 的浏览器端图片编辑器架构。

FB-49-SC-R-007：WebAssembly 未来可能如何改变前端开发？