WebAssembly（Wasm）是一种面向 Web 的二进制指令格式与运行时（更准确说：一种可移植的低层字节码 + 校验/沙箱执行模型）。它被设计成在浏览器里快速、可预测、接近原生性能地执行，同时也可以在浏览器外（Node.js、Wasm runtimes）运行。
你可以把它理解为：==Web 里的“可移植、受限沙箱中的高性能模块”。
1) Wasm 解决什么问题
- 性能与确定性：适合 CPU 密集型任务（图像/音视频编解码、压缩、加密、物理仿真、CAD、科学计算、游戏引擎）。
- 复用既有代码：C/C++/Rust 等可编译到 Wasm，把成熟库带到 Web（如 ffmpeg、zlib、openssl 的替代/裁剪方案等）。
- 更小的分发与更快启动（视场景）：二进制通常比同等 JS 体积更小、解析更快（但也受网络、初始化、内存拷贝等影响）。
不适合/收益不大：
- DOM 操作与典型 UI 逻辑：Wasm 不能直接操作 DOM；频繁跨 JS/Wasm 边界会抵消收益。
- IO 密集业务：网络请求、数据库、业务编排等通常 JS/TS 更合适。
2) Wasm 在浏览器里的运行模型
- 沙箱：默认不能随意访问文件系统、网络、DOM；必须通过宿主（浏览器/JS）暴露的接口。
- 线性内存（Linear Memory）：Wasm 模块主要通过一块可增长的 ArrayBuffer 风格内存进行读写；复杂对象需要序列化/拷贝或用共享内存策略。
- JS ↔ Wasm 互操作成本：跨边界调用有开销；要尽量“批量处理”、减少来回调用和频繁数据拷贝。
- 安全：Wasm 不等于“更安全的原生代码”，但浏览器的沙箱 + 校验让它比直接跑本机二进制安全；仍要防内存越界类漏洞（逻辑层面）与供应链风险。
3) 典型架构
常见模式是：
- JS/TS 负责 UI、事件、DOM、网络
- ==Wasm 负责纯计算：
input bytes -> wasm -> output bytes== - 通过 TypedArray 在内存间传递数据（或用
SharedArrayBuffer做共享/多线程）
4) 多线程与 SIMD（性能相关）
- 线程：浏览器端 Wasm 多线程依赖
SharedArrayBuffer和相关安全策略（跨域隔离 COOP/COEP）。多线程通常在 Web Worker 里跑。 - SIMD：Wasm SIMD 可显著加速图像处理、音视频、数学运算等，但要注意不同浏览器/设备支持与回退策略。
- 性能现实：Wasm 很快，但“快”通常来自算法与批处理；如果主要瓶颈是 DOM/布局/网络，Wasm 帮助有限。
5) WASI 与“浏览器外 Wasm”
- WASI（WebAssembly System Interface）是让 Wasm 在非浏览器环境更像“可移植程序”的系统接口标准（文件、时钟、随机数等能力由宿主授予）。
- 对 Web 开发者意义：你可以写一份 Wasm 产物，在浏览器和服务器/边缘运行时复用部分逻辑（但接口与权限模型不同，仍需适配）。
6) 工具链与语言选择
- Rust → wasm-bindgen / wasm-pack：生态成熟，和 Web 互操作工具较好。
- C/C++ → Emscripten：历史最久，能把大量原生库搬到 Web（代价是构建复杂度与包体）。
- AssemblyScript：TS-like 语法，适合愿意牺牲部分能力换易用性的团队。
- TinyGo：Go 的一个方向，但与标准 Go 运行时/反射等存在限制（取决于项目需求）。
7) 版本化与组件化趋势
- Wasm Component Model（组件模型）与 WIT（接口类型描述）试图改善跨语言、跨运行时的互操作与分发体验（更像“包/组件”而不是“裸模块”）。
- 现阶段在浏览器侧仍在逐步成熟；短期内你更多还是用传统的 JS glue（比如 wasm-bindgen、Emscripten 输出的胶水代码）。
8) 工程上要注意的坑
- 包体与初始化：Wasm 本体 + 胶水代码 + 运行时（尤其 Emscripten）可能很大；要做按需加载、缓存、分包。
- 调试与可观测性：source map/符号、性能剖析比纯 JS 麻烦一些；要在构建时保留调试信息并熟悉浏览器 DevTools 的 Wasm 支持。
- 数据拷贝：大数组来回拷贝会很慢；尽量共享缓冲区、一次性传输、在 Wasm 内完成更多处理。
- 权限与隔离：多线程/共享内存需要站点启用 COOP/COEP；否则会遇到“为什么线程跑不了”的问题。