WebAssembly 支持哪些语言？项目里该怎么选？
WebAssembly 选语言，核心不是“哪门语言最强”，而是看代码来源、团队熟练度、包体预算和 JS 互操作成本。新写高性能模块通常优先考虑 Rust；迁移成熟 C/C++ 库时，Emscripten 更现实；前端团队做小型静态算法，可以评估 AssemblyScript；Go、C#、Kotlin 也能用，但要接受运行时体积和启动成本。Wasm 适合大块、稳定、可批处理的计算，不适合把 DOM 操作、网络请求和大量动态对象硬塞进去。
追问
新项目为什么经常推荐 Rust？
Rust 的优势是内存安全、无传统 GC、工具链成熟，wasm-pack 和 wasm-bindgen 能把构建、绑定和 npm 发布流程串起来。它适合图像处理、压缩、加密、解析器这类既要性能又怕内存错误的场景。取舍是学习成本不低，生命周期和所有权会拖慢前期开发；如果团队没人能维护，后期反而会变成风险。还有一个坑是 JS 和 Rust 之间传字符串、对象并不免费，最好一次传入缓冲区，而不是频繁调用小函数。
cargo install wasm-pack wasm-pack build --release --target web
已有 C/C++ 代码是不是直接用 Emscripten？
如果已有库很成熟，比如 FFmpeg、SQLite、物理引擎或游戏引擎核心，Emscripten 往往比重写划算。它能模拟部分 POSIX 能力，也能处理 STL、文件系统、线程等复杂场景。边界是产物通常更大，胶水代码更多，异常、RTTI、线程都会增加体积和兼容成本。C/C++ 的越界问题也不会因为进了 wasm 就消失，只是破坏范围通常被限制在线性内存和沙盒里。
emcc main.cpp -O3 -s WASM=1 -s MODULARIZE=1 -o app.js
AssemblyScript 适合 TypeScript 团队吗？
适合一部分场景，尤其是算法规则清晰、类型静态、标准库依赖少的小模块。它语法像 TypeScript，上手快，前端团队沟通成本低。踩坑是它不是“把任意 TS 编译成 wasm”，动态对象、复杂闭包、反射和大量 npm 依赖都不适合直接搬。若代码本来高度依赖 JS 生态，继续用 TypeScript 可能比上 Wasm 更稳。
npm i --save-dev assemblyscript npx asc assembly/index.ts --target release --outFile build/module.wasm
Go、C# 这类语言什么时候值得选？
当目标是复用现有团队资产时，它们值得考虑，比如 .NET 团队用 Blazor WebAssembly 做完整应用，或 Go 团队复用一段核心算法。问题是运行时和胶水层较重，小工具模块可能为了几百行逻辑带上不小的包体。边界在首屏性能：冷启动、下载和实例化时间可能吃掉计算收益。别只看 hello world，要用真实业务输入比较 gzip 后体积、初始化时间和调用耗时。
最终怎么拍板？
可以用一周做基准验证：同一段核心逻辑用候选语言各写一个最小版本，比较包体、冷启动、核心函数耗时、调试体验和 CI 复杂度。新写模块优先 Rust，迁移老 C/C++ 优先 Emscripten，小型前端算法试 AssemblyScript，完整 .NET 应用再看 Blazor。若逻辑需要频繁操作 DOM、拼对象、走网络，WebAssembly 不一定更快。语言选择不是信仰题，而是性能收益、维护成本和团队能力的平衡。