Emscripten 编译 Wasm 极限瘦身：深度解析禁用 C++ 异常的方案与避坑指南

在将 C/C++ 项目编译为 WebAssembly（Wasm）并部署到 Web 端时，文件体积通常是决定用户加载体验的关键指标。

许多开发者在初次使用 Emscripten 编译项目时会发现，即使是一个逻辑简单的 C++ 库，生成出来的 .wasm 和 .js 胶水代码也异常庞大。这其中，C++ 异常处理（Exception Handling）机制往往是隐形的“体积杀手”。

本文将深入探讨为什么 C++ 异常会导致 Wasm 体积暴增，并手把手教你如何通过 Emscripten 安全、彻底地禁用异常，以及如何应对禁用后带来的副作用。

为什么 C++ 异常会让 Wasm 体积暴增？

在传统的 native（如 Windows/Linux）开发中，C++ 异常通过零成本异常模型（Zero-cost Exception Handling）实现，只有在抛出异常时才会有性能损耗。

然而，WebAssembly 标准早期并不支持原生的异常处理。为了让 C++ 的 try-catch、throw 以及析构函数的自动调用（RAII）在浏览器中正常工作，Emscripten 默认不得不采用基于 JavaScript 模拟的异常处理机制。

这种模拟机制会带来两个严重的副作用：

1. 生成大量 JS 胶水代码：Emscripten 必须生成复杂的 JavaScript 包装函数，通过 JS 的 try-catch 来捕获和分发 C++ 抛出的指针异常。
2. 阻碍编译器优化：为了保证在发生异常时能正确回溯堆栈并释放局部变量（Unwinding），编译器必须在每个可能抛出异常的函数周围插入大量的清理代码。这直接导致生成的 .wasm 二进制文件体积大幅膨胀（通常增加 20% 到 50% 不等，甚至更多）。

方案一：彻底禁用异常（最彻底的瘦身方案）

如果你的项目不需要依赖 try-catch 来处理业务逻辑（例如高性能计算、图像处理、音频合成等模块），直接禁用异常是最高效的瘦身手段。

1. 核心编译选项

在编译时，你需要同时向编译器和链接器传递以下参数：

• -fno-exceptions：告诉 Clang 前端禁用 C++ 异常支持。编译器遇到 try、catch、throw 时会直接报错，且不再为局部变量生成析构清理代码。
• -sDISABLE_EXCEPTION_CATCHING=1（通常在 -O1 及以上优化等级中默认为 1）：明确指示 Emscripten 运行时不要生成任何用于捕获 C++ 异常的 JS 胶水代码。

2. 命令行编译示例

emcc main.cpp -o module.js \
  -O3 \
  -fno-exceptions \
  -sDISABLE_EXCEPTION_CATCHING=1

3. CMake 项目配置

如果你的项目使用 CMake 进行构建，可以在 CMakeLists.txt 中这样配置：

# 确保如果是 Emscripten 编译环境，则注入对应 flag
if(EMSCRIPTEN)
    # 禁用 C++ 编译器端的异常支持
    add_compile_options(-fno-exceptions)
    
    # 禁用链接器端的异常捕获胶水代码
    add_link_options(-sDISABLE_EXCEPTION_CATCHING=1)
endif()

禁用异常后的连锁反应与避坑指南

强行关闭异常虽然爽快，但如果你的代码或依赖的第三方库中包含异常逻辑，程序运行时就会发生灾难。以下是必须注意的几个坑：

1. 代码中残留 throw 会发生什么？

在开启 -fno-exceptions 后，如果你自己的代码中写了 throw，编译时 Clang 会直接报错：

error: cannot use 'throw' with '-fno-exceptions'

这是最安全的情况，你只需要重构该部分代码，将其改为返回错误码（如 std::optional 或 Result 模式）。

2. 标准库（STL）抛出异常怎么办？

诸如 std::vector::at()、std::make_shared（内存不足时）等标准库操作，在失败时默认会抛出异常。
在禁用异常后，标准库在触发这些错误时会直接调用 std::terminate()。在 Wasm 运行时中，这表现为程序直接 Crash，控制台打印类似如下的 Unreachable 错误：

RuntimeError: unreachable executed

应对策略：

• 避免使用会抛出异常的成员函数。例如，用 vector[index] 代替 vector.at(index)（当然，你需要自己确保索引不越界）。
• 在关键入口处，使用断言（assert）或者显式的 if 逻辑提前拦截非法输入。

3. 第三方静态库（.a）的异常冲突

这是最隐蔽的坑。如果你的项目链接了预编译好的第三方 .a 静态库，而该静态库在编译时开启了异常，而你的主项目禁用了异常：

• 链接时可能不会报错。
• 但运行时一旦该静态库内部抛出异常，由于主项目没有生成对应的 JS 捕获机制，整个 Wasm 模块会直接崩溃，且极难调试。

应对策略：
所有依赖的第三方库，必须使用相同的 -fno-exceptions 参数重新用 Emscripten 编译一次。

方案二：现代化替代方案 —— 启用 WebAssembly 原生异常（Wasm Exceptions）

如果你实在无法重构代码（例如代码中大量依赖第三方复杂库，无法剥离异常），但又对体积和性能有极高要求，那么可以尝试现代浏览器原生的 Wasm 异常处理提案。

现在，主流浏览器（Chrome 95+、Firefox 100+、Safari 15.2+）已经原生支持了 WebAssembly Exception Handling 提案。

如何启用？

使用 -fwasm-exceptions 替代 -fno-exceptions：

emcc main.cpp -o module.js \
  -O3 \
  -fwasm-exceptions

为什么选择原生 Wasm 异常？

• 体积大幅缩小：它不需要 Emscripten 在 JS 端生成庞大的 try-catch 包装器，所有的异常抛出和捕获都直接在 Wasm 虚拟机内部完成。
• 性能极高：因为省去了 JS 与 Wasm 频繁切换的开销，原生异常的执行效率接近 Native 速度。
• 保留了 try-catch 语义：你的 C++ 代码不需要做任何修改，原有的异常逻辑完全保留。

注意：启用 -fwasm-exceptions 会导致编译产物无法在一些老旧浏览器或旧版 Node.js 环境中运行。如果你的用户群体对浏览器版本没有苛刻限制，这绝对是目前最完美的折中方案。

总结：优化收益对比

根据实际项目（一个包含基础数据结构操作的 C++ 库）的编译测试，优化数据大致如下：

决策建议：

1. 追求极致体积 + 逻辑可控：果断选择 -fno-exceptions + -sDISABLE_EXCEPTION_CATCHING=1，用返回值代替异常。
2. 遗留代码多 + 现代浏览器环境：选择 -fwasm-exceptions，既要体积又要功能。