webassembly音频编码器默认单线程，因编译未启用线程支持、共享内存及宿主安全策略限制；启用并行需同时满足编译配置、http头策略、js内存实例三硬性前提，且并行应限于无依赖计算段。
能搬，但不能直接“搬运”——WebAssembly 模块本身不自带并行能力，必须显式启用线程支持、共享内存，并在宿主环境（浏览器）中满足安全策略，否则 SharedArrayBuffer 会静默失效，Rayon 或 pthread 级并行根本不会跑起来。
为什么 MP3/Opus 编码器在浏览器里默认是单线程的
绝大多数 WebAssembly 音频编码器（如 FFmpeg.wasm、libopus-wasm）默认编译时禁用线程：Emscripten 默认不开启 +atomics 和 +bulk-memory，且生成的模块未声明 shared memory。即使 Rust + Rayon 写了 par_iter()，运行时也会退化为串行。
- 浏览器控制台看不到报错，但
performance.now()对比会发现并行函数和普通iter().sum()耗时几乎一致 - 检查生成的
.wasm文件：用wabt的wasm-decompile module.wasm | grep memory，若无shared字样，说明内存不可共享 - FFmpeg.wasm 官方构建版（如 ffmpeg-core.js）至今未启用线程，因其依赖的 libswresample/libavcodec 内部同步逻辑与 WASM 线程模型尚未完全对齐
启用并行音频编码的三个硬性前提
缺一不可，漏掉任一环节，线程调用就会静默降级或抛 RuntimeError: unreachable。
- 编译时加
-s THREADS=1 -s ATOMICS=1 -s SHARED_MEMORY=1 -s MAXIMUM_MEMORY=2147483648（Emscripten）或rustflags = ["-C", "target-feature=+atomics,+bulk-memory,+threads"]（Rust + wasm-bindgen） - 服务端响应头必须包含
Cross-Origin-Embedder-Policy: require-corp和Cross-Origin-Opener-Policy: same-origin，否则SharedArrayBuffer构造失败 - JavaScript 加载模块时需显式传入
memory实例：new WebAssembly.Memory({ initial: 256, maximum: 2048, shared: true })，并在importObject中挂载
实际编码流程中如何避免线程卡死
音频编码不是纯计算，涉及输入缓冲、重采样、帧对齐等 I/O 敏感步骤，并行只应施加在可分割的计算段（如 MDCT 变换、量化环路），而非整个 encode() 函数。
- 不要对
Uint8Array音频原始数据直接调用par_chunks()—— 编码器内部有跨帧依赖（如 Huffman 表上下文、LPC 系数预测），切片后会输出损坏比特流 - 推荐做法：用 Web Worker 承载整个编码器实例，主线程只负责喂 PCM 数据块（如每 4096 样本）、接收编码完成事件；Worker 内部用单线程调用
encode_frame()，但把 FFT/MDCT 等子过程交给 Rayon 并行处理 - 内存复用关键：分配一块
SharedArrayBuffer，划分 input region / output region / temp region，避免每次 encode 都 new ArrayBuffer —— 否则 GC 压力会导致音频断续
Faust + WebAssembly 的并行化更可行但有局限
Faust 生成的 DSP 模块天然适合并行，因其信号流图本身就是数据并行结构，但仅限于实时滤波类场景，不适用于 MP3 这类有状态、非线性的编码器。
- Faust 编译时加
-lang wasm -threads 1可生成带Atomics.wait()的多线程版本，配合architecture/webaudio/wasm-standalone-node-wrapper.js使用 - 它能并行处理多个通道（stereo → dual mono），或对同一帧内不同频带做并行滤波，但无法加速熵编码、VBR 比特分配等 MP3 特有阶段
- 若目标是低延迟实时编码（如 WebRTC 前置处理），Faust + Opus encoder wrapper 是更稳的选择；若需完整 MP3 文件输出，仍得走 FFmpeg.wasm 路线并手动拆解并行边界
真正棘手的不是“能不能并行”，而是“在哪并行、并行多少、谁来同步”。浏览器里没有 pthread_mutex_t，所有跨线程状态协调都得靠 Atomics.compareExchange 和精心设计的 ring buffer，稍有不慎就出现音频撕裂或内存越界 trap —— 这些细节不会出现在任何“5 分钟上手”教程里。
