最高效WASM交互需避免malloc传指针，因涉及手动管理、UTF-8转换及内存泄漏；WASM 1.0仅支持i32/i64/f32/f64，struct/string须转偏移+长度；导出函数需EMSCRIPTEN_KEEPALIVE与EXPORTED_FUNCTIONS配对，并显式导出_free；字符串须带长度且用UTF-8；结构体需#pragma pack(1)防padding错位；内存不足时须调用memory.grow()。
直接用 malloc 分配内存再传指针给 JS 是最常见也最容易出错的做法——它看似简单，实则绕不开手动管理、字节偏移计算、UTF-8 编码转换和内存泄漏风险。真正高效的交互不靠“传得快”，而靠“少传、预对齐、不越界”。
为什么不能直接返回 struct* 或 std::string
WASM 1.0 标准只允许函数参数和返回值是四种基本类型：i32、i64、f32、f64。C++ 的 struct、std::string、std::vector 全部无法直传。所谓“返回字符串指针”，实际只是返回一个 i32 值，代表线性内存中的字节偏移地址。
- JS 拿到这个数字后，必须用
Uint8Array或Int32Array视图去读取对应位置的原始字节 - 如果 C++ 用
new或malloc分配内存，JS 完全不知道该从哪读、读多少、是否以\0结尾 - 没有长度信息或编码标识时，JS 无法安全转成
String；UTF-8 多字节字符可能被截断
EMSCRIPTEN_KEEPALIVE 和 EXPORTED_FUNCTIONS 必须配对使用
仅加 EMSCRIPTEN_KEEPALIVE 不足以让函数在 JS 中可用；Emscripten 默认会 strip 掉未引用的符号，导出必须显式声明。
- C++ 侧：函数需加
extern "C"防止 name mangling，并用EMSCRIPTEN_KEEPALIVE标记 - 编译命令中必须指定
-s EXPORTED_FUNCTIONS='["_my_func"]'，注意前缀下划线和引号格式 - 若函数返回指针（如
const char*），还需额外导出_free或自定义释放函数，否则内存永远不回收 - 不加
-s EXPORTED_RUNTIME_METHODS='["ccall","cwrap"]'时，JS 侧只能用Module._my_func()调用，不能用ccall自动处理类型转换
字符串传递必须带长度，且优先用 UTF-8
JS 的 TextEncoder / TextDecoder 默认操作 UTF-8，而 WASM 内存是纯字节数组。二者对齐才能避免乱码或崩溃。
Java 接口排错助手
下载
在调试 Java 后端 API 故障时使用此技能，尤其适用于以下任务：分析日志、跨 Controller、Service 和 Mapper 层追踪请求、定位异常根因、检查 SQL 执行或参数流转，以及生成简洁的诊断结论与修复方案。
立即学习“Java免费学习笔记（深入）”；
- C++ 中不要依赖
strlen—— JS 写入的字符串可能没\0结尾；应由 JS 显式传入长度参数 - 推荐接口设计：
int process_string(int ptr, int len)，C++ 用std::string_view(ptr, len)安全读取 - 返回字符串时，先
malloc分配空间，memcpy复制内容，再返回指针；JS 立即用decoder.decode(new Uint8Array(memory.buffer, ptr, len))解码 - 切忌在 C++ 里用
std::string.c_str()直接返回——栈上字符串生命周期结束即失效
结构体数组要手动布局，避免 padding 干扰
C++ 编译器会对 struct 插入 padding 字节以对齐内存，但 JS 读取时按固定偏移硬算，padding 会导致字段错位。
- 用
#pragma pack(1)或[[gnu::packed]]强制紧凑布局 - 结构体中避免混合使用
char、int32_t、double等不同对齐要求的成员，或统一用uint8_t数组模拟 - JS 侧用
DataView按字节顺序逐字段读取：view.getInt32(offset, true)（小端） - 若结构体含指针成员（如
char*），该指针本身仍是线性内存中的i32偏移，需二次解引用
最易被忽略的一点：WASM 线性内存初始大小默认只有 1 页（64KB），结构体数组稍大就会触发 RangeError: offset is out of bounds。每次写入前务必检查 memory.grow() 是否成功，而不是假设内存永远够用。
