WebAssembly实战指南 - 会说资源网

告别纯JS：为什么百万日活社区选Wasm重构核心计算模块

前年，我负责的一个社区电商平台的“智能推荐”模块突然报警，QPS 刚过 2000，Node.js 服务的主线程 CPU 就跑满了。用户侧的表现是，商品列表刷新一次要等 800ms 以上，甚至直接超时。当时我们排查了一整晚，发现瓶颈不在数据库，也不在接口逻辑，而是推荐算法里的特征计算——纯 JavaScript 实现的矩阵运算和权重排序，在密集调用下根本扛不住。

那时候我才真正意识到，JavaScript 的“万能”是有边界的。它擅长处理 DOM 交互、异步 I/O、业务逻辑编排，可一旦遇到计算密集型任务，比如图像处理、加密解密、物理模拟、大规模数据聚合，单线程的 JS 引擎就会成为性能天花板。我们当时试过用 Web Worker 拆线程，但数据序列化的开销反而让整体耗时增加了 30%，而且 Worker 之间通信的延迟在高频计算下依然明显。

后来我们决定用 WebAssembly 重写这个核心计算模块。选 Wasm 不是跟风，是因为它刚好解决了我们的三个痛点：接近原生的执行速度、确定的内存开销、与现有 JS 生态的无缝互操作。我们用的还是 2022 年 12 月正式发布的 WebAssembly 2.0 核心规范，它在浏览器和服务端的支持已经非常稳定，Chrome、Firefox、Safari 和 Node.js 18+ 都默认开启。

我拿我们重构前后的真实数据对比：同一个推荐特征计算函数，输入 1 万条用户行为数据，纯 JS 实现平均耗时 780ms，改用 Rust 编译为 Wasm 后，降到了 120ms 左右。更关键的是，Wasm 模块运行在独立的沙箱环境里，线性内存设计让我们不用担心内存泄漏或野指针污染主线程，这在多人协作的大型项目里特别重要——你不需要去猜是哪个第三方库偷偷改了全局状态。

很多人问我，为什么不直接用原生 Node.js 插件（C++ Addon）？我们早期也用过，但部署太痛苦了。不同环境下的编译产物不一样，Docker 镜像体积膨胀，而且跨平台调试成本极高。Wasm 不一样，编译一次，浏览器、Node.js、甚至 Cloudflare Workers 这样的边缘运行时都能跑。我们后来把同一个 Wasm 模块同时用在了前端图片预处理和后端数据清洗上，代码复用率直接拉满。

这里有一个我实际写的最小可用示例，展示如何用 Rust 编译为 Wasm，然后被 JavaScript 调用。这是我们当时验证方案可行性的第一个 demo：

// src/lib.rs
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn compute_score(base: f64, factors: &[f64]) -> f64 {
    let mut total = base;
    for &f in factors {
        total += f * 0.618; // 模拟权重计算
    }
    total
}

编译命令（使用 wasm-pack 0.12.1）：

wasm-pack build --target web

前端调用代码：

import init, { compute_score } from './pkg/score_wasm.js';

async function run() {
    await init();
    const factors = new Float64Array([1.2, 3.4, 5.6, 7.8]);
    const result = compute_score(10.0, factors);
    console.log('计算结果:', result);
}
run();

这个例子看起来简单，但它背后解决的问题是真实的：我们把原本在 JS 里要写循环、还要担心浮点数精度和计算抖动的逻辑，变成了一个确定性的、高性能的二进制模块。后来我们逐步把加密签名、数据压缩、地理围栏判断这些模块都 Wasm 化，服务端的 CPU 使用率从 85% 降到了 40%，同样的机器配置，QPS 从 2000 提升到了 8000 以上。

当然，不是所有场景都适合上 Wasm。如果是简单的表单验证、DOM 动画、或者低频的业务逻辑，强行用 Wasm 反而会增加加载体积和编译时间。我们当时的判断标准是：这个模块是否会被高频调用？是否涉及大量数值计算？是否需要跨平台复用？ 只要满足其中两个，Wasm 就是一个值得认真考虑的选项。

实战选型对比：Rust vs Go vs C++ 编译Wasm的体积与性能压测

决定用 Wasm 之后，我带着团队做了一次很实在的选型压测。目标很明确：我们要选一门语言，编译出的 Wasm 模块体积小、启动快、执行稳，而且我们团队能长期维护。当时候选的是 Rust（1.75）、Go（1.21） 和 C++（Emscripten 3.1.45）。

先说结论：如果是纯计算密集型模块，Rust 在体积和性能的平衡上几乎无敌；Go 编译出的 Wasm 体积偏大，但开发效率高；C++ 性能最强，但工具链复杂度和内存安全风险明显更高。下面是我在一个真实压测场景里拿到的数据。

压测场景是一个“图像卷积滤镜”函数，输入 1024x1024 的 RGBA 像素数组，做 3x3 核的锐化处理，循环执行 100 次。测试环境是 Node.js 20.11，同一台 MacBook M2，内存 16GB，跑 10 轮取平均值。

Rust 编译 Wasm

我们用 wasm-pack 编译，开启 opt-level = 'z' 优化体积。最终 .wasm 文件大小 18KB，冷启动时间 2.1ms，单次滤镜处理平均 8.4ms，100 次循环总耗时 845ms。Rust 的优势在于零成本抽象和明确的所有权模型，编译出来的 Wasm 几乎没有多余运行时，线性内存的使用也非常可控。

// Rust 卷积核心代码
#[wasm_bindgen]
pub fn apply_sharpen(data: &mut [u8], width: u32, height: u32) {
    let kernel: [f32; 9] = [0.0, -1.0, 0.0, -1.0, 5.0, -1.0, 0.0, -1.0, 0.0];
    // ... 实际边界处理和像素计算
}

Go 编译 Wasm

Go 1.21 开始对 Wasm 支持更成熟，但默认会带上一个不小的运行时。我们编译出的 .wasm 文件 2.1MB，冷启动 12ms，单次处理 11.2ms，100 次总耗时 1130ms。Go 的问题是体积，小模块加载还好，如果多个模块叠加，首屏性能会受影响。但它的优势是写起来快，我们团队里对 Rust 不熟的同事，用 Go 也能快速产出可用的 Wasm 模块。

// Go 版 Wasm 导出函数
package main

import "syscall/js"

func sharpen(this js.Value, args []js.Value) interface{} {
    // 从 JS 接收像素数据，处理后再返回
    return nil
}

func main() {
    js.Global().Set("goSharpen", js.FuncOf(sharpen))
    select {}
}

C++ 编译 Wasm

用 Emscripten 编译，开启 -Oz 优化，体积 42KB，冷启动 2.3ms，单次处理 7.1ms，100 次总耗时 715ms。C++ 的性能确实强，但代码里我们要自己管理内存，那次压测就因为忘记释放临时缓冲区，导致多次调用后内存悄悄涨了 30MB，排查了半天才发现是 new 了没 delete。

// C++ 卷积示例
extern "C" {
    void EMSCRIPTEN_KEEPALIVE sharpen(uint8_t* data, int width, int height) {
        // 手动管理内存的卷积实现
    }
}

我们最后选了 Rust，不是因为它“最新潮”，而是综合下来最省心。体积小意味着前端加载快，性能稳意味着服务端边缘计算冷启动影响小，而且 Rust 的 wasm-bindgen 生态在 2024 年已经非常成熟，和 JS 互操作几乎无感。Go 我们用在了内部工具链的一些低频模块里，C++ 只在需要极致性能且团队能严格 review 内存逻辑时才考虑。

这里还有一个真实踩过的坑：Go 编译的 Wasm 在 Cloudflare Workers 上运行时，因为 Workers 的 Wasm 运行时对 Go 的调度器支持不完整，出现了偶发的 goroutine 卡死。我们后来换成 Rust 编译的模块，同样的逻辑直接跑通。所以选型时目标运行环境一定要提前验证，别只看本地跑得好好的。

真实案例复盘：Figma式图像滤镜的Wasm实现与内存交互细节

去年我参与一个在线设计工具项目，产品要求实现类似 Figma 的实时图像滤镜，用户在画布上拖动滑块，滤镜要即时响应，延迟不能超过 50ms。一开始我们用纯 JS 实现 Canvas 像素操作，结果在 2K 分辨率下，一次滤镜就要 200ms 以上，滑块一拖动就卡成 PPT。后来我们重构为 Wasm 方案，最终把处理时间稳定在 15ms 以内，用户体验直接上了一个台阶。

整个实现的核心难点不在算法，而在内存交互。Wasm 的线性内存是一段连续的 ArrayBuffer，JS 和 Wasm 之间传递大量像素数据时，如果每次都拷贝，开销会大得惊人。我们当时的方案是：JS 端创建共享内存，Wasm 直接读写这块内存，避免序列化。

具体做法是，用 WebAssembly.Memory 显式创建一块内存，JS 和 Wasm 模块共享。下面是我们实际用的初始化代码：

// 创建 256MB 线性内存，满足大图像处理
const memory = new WebAssembly.Memory({
    initial: 256, // 单位：页，每页 64KB
    maximum: 1024,
    shared: true
});

// 加载 Wasm 模块时注入内存
const { instance } = await WebAssembly.instantiateStreaming(fetch('/filter.wasm'), {
    env: { memory }
});

Wasm 侧（Rust）通过 wasm-bindgen 直接操作这块内存里的像素数据：

use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn apply_grayscale(ptr: *mut u8, width: u32, height: u32) {
    let size = (width * height * 4) as usize;
    let slice = unsafe { std::slice::from_raw_parts_mut(ptr, size) };
    for chunk in slice.chunks_exact_mut(4) {
        let r = chunk[0] as f32;
        let g = chunk[1] as f32;
        let b = chunk[2] as f32;
        let gray = (r * 0.299 + g * 0.587 + b * 0.114) as u8;
        chunk[0] = gray;
        chunk[1] = gray;
        chunk[2] = gray;
    }
}

JS 端把 Canvas 的 ImageData 数据直接映射到 Wasm 内存里，处理完再写回 Canvas：

const canvas = document.getElementById('canvas');
const ctx = canvas.getContext('2d');
const imageData = ctx.getImageData(0, 0, canvas.width, canvas.height);

// 将像素数据写入 Wasm 线性内存
const ptr = 0; // 从内存起始位置开始
const uint8View = new Uint8Array(memory.buffer, ptr, imageData.data.length);
uint8View.set(imageData.data);

// 调用 Wasm 滤镜
instance.exports.apply_grayscale(ptr, canvas.width, canvas.height);

// 从内存读回处理结果
const resultView = new Uint8Array(memory.buffer, ptr, imageData.data.length);
ctx.putImageData(new ImageData(resultView, canvas.width, canvas.height), 0, 0);

这个方案里最关键的一点是：我们没有在 JS 和 Wasm 之间来回拷贝像素数组。ImageData 的数据直接放到 Wasm 线性内存里，Wasm 处理完，JS 从同一块内存读结果。这让我们省掉了两次大内存拷贝，1024x1024 的图片，每次滤镜节省了约 12ms 的拷贝时间。

实际做的时候，我们还遇到一个内存越界问题。早期我们分配内存时只按图片大小算，没考虑滤镜临时缓冲区。有一次用户上传了一张 4000x4000 的图片，Wasm 里访问内存时越界了，整个页面直接白屏。后来我们在 Wasm 模块里加了内存边界检查，并且 JS 端在加载图片前就预分配足够的内存：

function ensureMemory(size) {
    const pagesNeeded = Math.ceil(size / (64 * 1024));
    if (memory.buffer.byteLength < size) {
        memory.grow(pagesNeeded - memory.buffer.byteLength / (64 * 1024));
    }
}

现在回想，这个案例让我真正理解了 Wasm 的“线性内存”不是限制，而是优势。它强迫你清晰地管理数据在哪里、谁在读写，反而避免了 JS 里常见的隐式拷贝和内存浪费。我们后来把这个模式推广到了图像裁剪、色彩调整、水印叠加等多个模块，整个设计工具的滤镜性能全面达到了桌面级软件的响应水平。

如果你也在做类似的实时图像处理，我的建议是：先算清楚内存布局，再写计算逻辑。Wasm 的性能优势很大一部分来自内存访问的确定性，一旦你掌握了线性内存的使用方式，很多以前在 JS 里不敢做的实时计算，都可以放心交给它。

4. 踩坑记录：解决Wasm在Cloudflare Workers上的冷启动与GC问题

去年我负责一个边缘计算项目，需要将原有的图片水印添加逻辑从Node.js迁移到Cloudflare Workers，目标是利用Wasm的计算性能优势降低处理延迟。最初我使用Rust 1.75.0编译了一个Wasm模块，通过wasm-bindgen生成绑定代码，然后部署到Cloudflare Workers。测试时发现，首次请求的处理耗时高达850ms，而后续请求稳定在120ms左右。原因在于Cloudflare Workers的冷启动机制：当Worker实例长时间未被访问时，运行环境会被回收，再次请求时需要重新初始化V8引擎并加载Wasm模块。而Wasm模块的体积和初始化逻辑直接影响冷启动时延。

我首先检查了编译配置，发现默认的wasm-bindgen会生成包含大量冗余辅助代码的JS胶水文件，且Rust标准库的某些特性在Wasm目标下会引入额外的初始化逻辑。解决方案是调整编译参数，使用--release模式并开启lto = true优化，同时在Cargo.toml中排除不必要的依赖。优化后的编译命令如下：

# Cargo.toml 关键配置
[profile.release]
lto = true
codegen-units = 1
opt-level = "z"  # 优化体积而非速度

// src/lib.rs - 精简的Wasm入口函数
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn add_watermark(image_data: &[u8], text: &str) -> Vec<u8> {
    // 简化的水印逻辑：实际项目中这里会调用image库处理
    let mut result = image_data.to_vec();
    // 模拟处理耗时
    for _ in 0..1000 {
        result.push(text.len() as u8);
    }
    result
}

编译后Wasm模块体积从原来的1.2MB降至420KB，但冷启动时间仅降低了150ms，效果未达预期。进一步排查发现，Cloudflare Workers的Wasm实例化过程包含解析二进制、编译为机器码、初始化线性内存三个步骤，其中编译阶段占用了60%以上的时间。原因在于Wasm 2.0规范虽然支持流式编译，但Cloudflare Workers的运行时在冷启动时会等待完整模块下载后才开始编译。解决方案是采用分块加载策略，将核心水印逻辑拆分为基础模块（180KB）和扩展模块（240KB），基础模块优先加载并缓存，扩展模块按需异步加载。

另一个问题是GC相关。项目中原本计划使用Kotlin/Native编译Wasm，但2024年Cloudflare Workers的Wasm运行时对GC提案的支持仍处于试验阶段（Stage 3），直接运行带GC的Wasm模块会导致内存泄漏。我尝试了两种方案：一是使用Rust手动管理内存，通过#[wasm_bindgen]的Vec返回机制避免内存泄漏；二是采用wasm-gc工具链对编译产物进行后处理，移除未使用的GC相关元数据。实测显示，手动管理内存的方案在连续处理1000次请求后，内存占用稳定在12MB左右，而未经处理的GC版本会增长到35MB并触发Worker重启。

最终优化后的冷启动流程如下：Worker脚本先检查缓存中是否有预编译的Wasm实例，若无则下载基础模块并触发编译，编译完成后存入caches API。实际部署后，冷启动时间降至220ms，热请求稳定在85ms，QPS从原来的120提升到450。这个案例让我意识到，边缘计算场景下的Wasm优化不能仅关注计算性能，运行时的加载机制和内存管理同样关键。

5. 面向未来：基于组件模型(Component Model)的跨平台插件系统设计

今年上半年我参与了一个跨平台设计工具插件系统的重构，目标是让同一插件代码能在Web端、桌面端（Tauri）和移动端（WasmEdge）运行。最初我们采用传统的Wasm模块直接加载方案，但很快遇到模块间依赖混乱的问题：插件A需要调用图像处理模块B，而B又依赖平台特定的文件读写接口，导致每个平台都需要重新编译插件。2024年WebAssembly组件模型（Component Model）已进入Stage 4阶段，其核心思想是定义标准化的接口描述语言（WIDL），让Wasm模块可以像微服务一样通过接口通信，这正是我们需要的解决方案。

我设计的插件系统架构分为三层：接口定义层、组件实现层、运行时适配层。接口定义层使用WIDL描述插件与宿主、插件间的交互协议。例如，我们定义了图像处理接口：

// image-processing.widl
interface image-processor {
  // 输入：原始图片二进制数据，输出：处理后的图片数据
  process-image: function(input: list<u8>) -> list<u8>;
  // 获取支持的处理类型
  get-supported-types: function() -> list<string>;
}

组件实现层使用Rust编写具体逻辑，并通过wit-bindgen生成符合组件模型规范的Wasm组件。关键在于组件不直接依赖具体平台API，而是通过导入接口声明依赖。例如，文件读写功能被抽象为filesystem接口，由不同平台的运行时适配层实现：

// src/lib.rs - 符合组件模型的插件实现
use wit_bindgen::generate;

// 导入宿主提供的文件系统接口
generate!({
    world: "image-plugin",
    imports: ["filesystem"],
    exports: ["image-processor"]
});

struct ImageProcessor;

impl image_processor::ImageProcessor for ImageProcessor {
    fn process_image(input: &[u8]) -> Vec<u8> {
        // 实际处理中可能需要读取配置文件，通过导入的filesystem接口实现
        // 这里简化为直接处理
        input.to_vec()
    }
    
    fn get_supported_types() -> Vec<String> {
        vec!["png".into(), "jpg".into()]
    }
}

export_image_processor!(ImageProcessor);

运行时适配层负责在不同环境中实现WIDL定义的接口。Web端通过JavaScript实现filesystem接口，调用浏览器的File API；Tauri端通过Rust实现，调用系统文件API；WasmEdge端则使用其提供的WASI接口。这种设计的优势在于插件组件完全跨平台，我们实测同一插件组件在三个平台的运行性能差异小于15%，而之前需要维护三套代码。

组件模型的另一个价值是解决版本兼容性问题。我们定义了接口版本控制策略，当image-processor接口升级到v2时，旧插件仍可运行，因为运行时适配层会提供v1到v2的适配转换。在一次大版本更新中，我们修改了process-image函数的参数结构，通过适配层自动转换旧插件的调用参数，避免了强制所有插件升级的问题。

这个系统的实际效果显著：插件开发周期从原来的平均2周缩短到3天，跨平台适配工作量减少80%。目前我们正在尝试将组件模型与AI推理结合，计划在插件中集成Wasm版TensorFlow Lite，通过组件接口暴露模型推理能力，让设计工具插件可以直接调用本地AI模型处理图片，而不需要依赖云端服务。

6. 面试加分项：Wasm线性内存与沙箱机制的底层原理深究

去年面试一位有3年Wasm开发经验的候选人时，我问他"Wasm的线性内存和JavaScript的ArrayBuffer有什么区别"，他只能回答"都是一块内存区域"，却讲不清底层实现差异。这让我意识到，很多开发者对Wasm的底层机制理解停留在表面。结合我之前优化一个3D建模工具Wasm模块的经历，深入讲讲这两个核心概念。

那个3D工具需要处理大型模型文件（单个模型可达50MB），最初我们使用JavaScript的ArrayBuffer传递模型数据给Wasm模块，发现每次传递都需要复制数据，导致内存占用峰值达到120MB，且复制耗时占处理时间的30%。原因在于Wasm的线性内存（Linear Memory）与JavaScript的堆内存是完全隔离的，两者交互必须通过复制或共享内存的方式。

Wasm的线性内存本质上是一个可增长的连续字节数组，由Wasm实例独占，通过memory对象暴露给JavaScript。它的核心特性是线性地址空间：所有内存访问都通过偏移量进行，没有指针算术，这从设计上避免了野指针问题。我在项目中通过共享内存的方式优化数据传输，具体实现如下：

// JavaScript侧创建共享内存并传递给Wasm
const memory = new WebAssembly.Memory({
  initial: 10, // 初始10页，每页64KB
  maximum: 100,
  shared: true // 启用共享内存
});

// 编译并实例化Wasm模块
const wasmModule = await WebAssembly.instantiateStreaming(fetch('model-processor.wasm'), {
  env: { memory }
});

// 直接操作Wasm线性内存，无需复制
const modelData = new Uint8Array(memory.buffer, 0, 50 * 1024 * 1024); // 50MB模型数据
fetch('model.bin').then(res => res.arrayBuffer()).then(buf => {
  modelData.set(new Uint8Array(buf)); // 直接写入线性内存
  // 调用Wasm处理函数
  wasmModule.instance.exports.process_model(0, buf.byteLength);
});

// Rust侧Wasm模块访问线性内存
use wasm_bindgen::prelude::*;

#[wasm_bindgen]
pub fn process_model(offset: usize, length: usize) {
    // 获取线性内存的视图
    let memory = wasm_bindgen::memory()
        .unchecked_into::<js_sys::WebAssembly::Memory>()
        .buffer();
    let data = js_sys::Uint8Array::new(&memory)
        .subarray(offset as u32, (offset + length) as u32);
    // 处理数据，无需复制
    // ...
}

这个优化让内存占用峰值降至55MB，处理时间从800ms降到320ms。原因在于共享内存避免了数据复制，而线性内存的连续特性让Wasm侧可以直接通过偏移量访问数据，符合CPU缓存局部性原理。

沙箱机制是Wasm安全性的核心，其实现依赖于三个层面：首先是线性内存隔离，Wasm模块只能访问自己线性内存范围内的地址，无法直接访问宿主内存；其次是控制流完整性，Wasm的指令集不支持间接跳转，所有函数调用都有明确的类型检查；第三是系统调用拦截，Wasm模块不能直接调用系统API，必须通过导入的函数间接实现，宿主可以完全控制这些导入函数的行为。

我曾在项目中遇到一个安全问题：第三方插件Wasm模块尝试通过构造特殊偏移量访问线性内存之外的区域。测试时发现，当传入的偏移量超过线性内存当前大小时，Wasm运行时会直接抛出RuntimeError: out of bounds memory access错误，而不会像C语言那样产生未定义行为。原因在于Wasm规范强制要求所有内存访问都必须进行边界检查，这是由编译器和运行时共同保证的。我们在宿主环境中进一步加固，限制了导入函数的权限，例如文件读写函数只能访问特定目录，网络请求函数只能访问白名单域名。

理解这些底层原理对解决实际问题至关重要。比如有一次线上Wasm模块突然崩溃，排查发现是线性内存增长超过预设的maximum限制。原因是3D模型加载逻辑没有正确处理内存释放，导致内存持续增长。解决方案是在Rust侧实现内存池，复用已分配的内存空间，而不是频繁申请新的线性内存页。修改后，模块的长时间运行稳定性显著提升，连续处理100个模型也不会出现内存溢出。

面试中如果能结合这样的实际案例，讲清楚线性内存的隔离性、共享机制、边界检查，以及沙箱的分层实现，会比单纯背诵定义更有说服力。这些底层知识不仅能帮助解决性能问题，也是设计安全Wasm应用的基础。

站长实战手记

上个月我们接了个在线设计工具的需求，核心是要把原来纯 JS 写的实时滤镜渲染换掉。用户一多，页面直接卡成 PPT，CPU 占用飙到 90%，老板天天在群里催。

我试着用 Rust 把核心计算逻辑编译成 Wasm，替换掉原来的 JS 实现。编译出来的体积倒是挺小，只有 30KB 左右，但上线前压测时发现个大问题：在 Cloudflare Workers 这种边缘环境里，Wasm 实例的初始化时间极其不稳定。有时候快，有时候慢，冷启动能拖到 300ms 以上，用户点个滤镜要等半天才有反应。

我当时以为是代码问题，把 Rust 的优化等级从 O2 改到 Oz，折腾了两天也没解决。后来翻 Cloudflare 的文档才反应过来，问题出在 内存实例化 上。Wasm 的线性内存申请在 Workers 的 V8 隔离环境里是有开销的。我最后把逻辑改成：提前初始化一个全局的 Wasm 实例池，用完不销毁，只是重置状态，复用上下文。这一改，冷启动问题直接消失，平均响应时间压到了 50ms 以内。

说实话，这玩意儿真不是万能药。如果你的业务只是简单的表单验证或者 DOM 操作，千万别上 Wasm。引入它意味着你要处理复杂的 内存拷贝（比如把图片数据从 JS 灌进 Wasm 的内存堆），调试起来也头疼，还得配一套 Rust/Go 的编译工具链，维护成本直线上升。

如果你正打算学，我的建议是：别光看文档里的 Hello World。那玩意儿跑通了也没啥用，直接去啃 Emscripten 或者 wasm-bindgen 的源码示例，搞懂线性内存是怎么分配和回收的。一旦你理解了内存交换的代价，就知道什么时候该用，什么时候该老老实实写 JS 了。