最简单的方法是列出目前无法与 WebAssembly 协同工作的部分；避免这些部分的箱子通常可以移植到 WebAssembly，并且通常可以“直接工作”。一个好的经验法则是，如果一个箱子支持嵌入式和 #![no_std] 使用，它可能也支持 WebAssembly。

wasm 中没有系统库，因此任何尝试绑定到系统库的箱子都无法工作。

使用 C 库也可能无法正常工作，因为 wasm 没有用于跨语言通信的稳定 ABI，并且 wasm 的跨语言链接非常挑剔。每个人都希望这最终能正常工作，尤其是现在 clang 默认情况下提供 wasm32 目标，但目前还没有实现。

WebAssembly 无法访问文件系统，因此假设存在文件系统的箱子（没有 wasm 特定的解决方法）将无法工作。

有计划将线程添加到 WebAssembly，但尚未发布。尝试在 wasm32-unknown-unknown 目标上生成线程会导致 panic，从而触发 wasm 陷阱。

提供特定算法或数据结构实现的箱子，例如 A* 图搜索或伸展树，通常可以与 WebAssembly 很好地协同工作。

不依赖标准库的箱子 通常可以与 WebAssembly 很好地协同工作。

解析器（只要它们只是接收输入而不执行自己的 I/O）通常可以与 WebAssembly 很好地协同工作。

处理文本形式表达的人类语言复杂性的箱子 通常可以与 WebAssembly 很好地协同工作。

针对 Rust 编程的特定情况的共享解决方案 通常可以与 WebAssembly 很好地协同工作。