必须显式导出函数、手动管理线性内存、等待module初始化完成：用extern "c"和emscripten_keepalive声明函数，-s exported_functions指定导出，js通过module._func调用；字符串/数组需在heap上读写；须在onruntimeinitialized或module() then后调用。
能直接引入，但必须绕过 JavaScript 的执行瓶颈，且不能指望“编译完就跑通”。关键在三件事：函数导出方式、内存管理归属、运行时初始化时机。
emcc 编译时必须显式导出 C++ 函数
默认情况下，C++ 函数会被名字修饰（name mangling），JavaScript 根本找不到入口。更糟的是，未被引用的函数会被 LTO 优化掉——哪怕你写了 add，不导出就等于不存在。
- 用
extern "C"包裹函数声明，禁用 C++ 名字修饰 - 加
EMSCRIPTEN_KEEPALIVE宏（头文件需#include <emscripten.h></emscripten.h>），防止链接期被裁剪 - 编译命令里必须指定
-s EXPORTED_FUNCTIONS='["_add"]'，注意函数名前带下划线 - 如果要用
Module._add()调用，_add必须出现在EXPORTED_FUNCTIONS里，缺一个字符都报Module._add is not a function
字符串和数组不能直接传，得手动管理线性内存
WebAssembly 没有“字符串”或“vector”概念，只有线性内存（Module.HEAP8 / Module.HEAP32 等）。JS 传字符串过去，C++ 端看到的只是个指针；C++ 返回数组，JS 得自己从内存切片读取。
- C++ 端分配内存用
malloc()，释放用free()；JS 端调用前记得Module._malloc()，调用后Module._free() - 字符串传入：JS 用
Module.lengthBytesUTF8()和Module.stringToUTF8()写入内存，再把地址传给 C++ 函数 - 字符串传出：C++ 返回指针 + 长度，JS 用
Module.UTF8ToString(ptr, len)解码 - 别依赖
std::string或std::vector直接跨边界——它们内部内存不在 WASM 堆上，JS 访问会崩溃
Module 初始化完成前，任何 _ 函数调用都会失败
Module 不是立即可用的对象。它要加载 .wasm、申请内存、运行 _start、执行全局构造器……这些全异步。早于 onRuntimeInitialized 或 Module().then() 调用 _add，结果一定是 undefined 或 RuntimeError: abort。
- 老式写法：
Module.onRuntimeInitialized = () => { Module._add(1, 2) } - 新式写法（推荐）：
Module().then(instance => instance._add(1, 2))，前提是编译时加了-s MODULARIZE=1 - 如果页面已加载 JS 胶水文件但没触发初始化（比如脚本放
但没等 DOM 就调用），也会卡住——务必确认Module.instantiateWasm已执行成功
性能不是白来的，-O3 和 ALLOW_MEMORY_GROWTH 得按场景选
没开优化的 WASM 可能比 JS 还慢；而盲目开 ALLOW_MEMORY_GROWTH=1 会导致每次扩容都重分配整个内存视图，GC 压力翻倍。
-
-O3必开，但调试时加-g，否则 Chrome DevTools 里看不到源码映射 - 固定大小计算（如矩阵乘法）：关
ALLOW_MEMORY_GROWTH，预设足够大的初始堆（-s INITIAL_MEMORY=67108864表示 64MB） - 处理用户上传图片：开
ALLOW_MEMORY_GROWTH=1，但要在 JS 层监控Module.buffer.byteLength，避免无限增长 - 图像处理类任务可加
-msimd128和-s SIMD=1，但注意 Safari 目前不支持 SIMD，得降级兜底
最常被忽略的其实是运行时模拟层：printf、fopen、std::cout 全靠 Emscripten 自己实现的虚拟文件系统和流缓冲。一旦 C++ 代码依赖真实文件 I/O 或线程同步原语，就得换 WASI 或手动 stub，不是改几个编译参数能解决的。
C++免费学习笔记（深入）：立即使用
在学习笔记中，你将探索 C++ 的入门与实战技巧！
