SharedArrayBuffer 的 16÷4 陷阱：一个让 AudioWorklet 数据错位的字节幻觉

"周末把 stw-sentinel 刚推上 npm，本以为这种偏底层的轮子没多少人关注，没想到短短两天就引来了不少同行的围观和测试，后台甚至抓到了在 Lab 页面死磕了十几分钟的硬核访客。看来大家平时在 V8 性能监控上都没少吃暗亏。趁着热度，今天聊聊做这个工具时，差点让我死锁的一个 SharedArrayBuffer 内存陷阱……"

1. 现象：明明没报错，数据全错了

你用 SharedArrayBuffer 搭了一个 AudioWorklet 通信管道，写入的数据读出来全是乱码。

不是数据损坏。不是跨线程竞争。不是字节序问题。

是你把字节偏移当成了元素索引。

这个 bug 的症状极其诡异：主线程写入的采样数据，Worklet 线程读出来完全对不上，但 SAB 本身没坏，Atomics 也正常工作。你开始怀疑是锁的问题、是采样率的问题、是浏览器兼容性问题——全错。根源只有一个：16 字节的 header，在 Int32Array 里的索引是 4，不是 16。

2. 陷阱解剖：字节不是元素

SharedArrayBuffer 本质是一块裸内存。你可以在上面建多种视图——Int32Array、Float32Array、Uint8Array——它们共享同一段底层 ArrayBuffer，但索引含义完全不同：

• Uint8Array[sab, 0, 16]：索引 0-15，每个元素 1 字节
• Int32Array[sab, 0, 4]：索引 0-3，每个元素 4 字节

两种写法覆盖的字节数都是 16，但索引空间完全不同。

这是陷阱的核心：

// ❌ 错误：把字节偏移当元素索引
const HEADER_SIZE = 16; // 16 字节

const header = new Int32Array(sab, 0, HEADER_SIZE); // 16 个 Int32 元素 = 64 字节！
const data = new Float32Array(sab, HEADER_SIZE * 4); // 偏移 64 字节，完全错位

// ✅ 正确：字节偏移是字节偏移，元素索引是元素索引
const HEADER_BYTES = 16;
const headerElements = HEADER_BYTES / 4; // 4 个 Int32 元素

const header = new Int32Array(sab, 0, headerElements); // 4 元素 = 16 字节
const data = new Float32Array(sab, HEADER_BYTES);      // 从第 16 字节开始

错误版本里，Int32Array(sab, 0, 16) 创建了 16 个 Int32 元素，占 64 字节。你的 header 本该占 16 字节，实际占了 64 字节，后面的数据区起始位置跟着偏移了 48 字节。

更阴险的是：数据不会报错。Int32Array 和 Float32Array 都能正常读写，Atomics 操作也不报异常。你的监控面板上看到的只是“数据对不上”，没有任何 red flag 告诉你偏移算错了。

3. 为什么这坑这么难发现

前端开发者对“字节对齐”几乎没直觉。JavaScript 层面你碰不到字节，new ArrayBuffer(16) 对你来说就是“16 个槽位”，很少去想这 16 个槽位的单位是什么。

调试时 console.log 打出来全是 Int32 值，看不出偏移问题——因为值本身没坏，只是写到了错误的内存位置。只有一种情况能暴露这个 bug：AudioWorklet 的实时数据流。因为 Worklet 的 process() 回调每 128 帧跑一次（约 2.67ms），数据是流式消费的，错位就是错位，没有重传机制。

这也是为什么这个 bug 在非实时场景下不容易触发——如果你的 SAB 只用来传配置参数，写错偏移最多是初始化失败，加个 try-catch 就能定位。但 AudioWorklet 的实时性要求让偏移错误变成了“数据流永远对不齐”的幽灵。

4. 第二个坑：AudioContext.resume()

这个坑更隐蔽，但杀伤力更大。AudioWorklet 的 process() 回调根本不跑，没有任何报错，控制台干净得像没加载过。

原因是 AudioContext 在现代浏览器中默认 state = 'suspended'。你必须调用 audioContext.resume() 才能启动处理管线，而这个调用必须放在用户手势（click/touch）的回调里，否则浏览器会忽略。

// ❌ 错误：自动调用，浏览器静默拒绝
const ctx = new AudioContext({ sampleRate: 48000 });
await ctx.audioWorklet.addModule('processor.js');
// process() 永远不跑，state 还是 suspended

// ✅ 正确：在用户手势后 resume
document.getElementById('startBtn').addEventListener('click', async () => {
  await ctx.resume(); // 现在 state = 'running'
  // process() 开始执行
});

state = 'suspended' 时不报错，这是最毒的地方。你以为代码有 bug，其实代码没问题，是生命周期没接上。

5. 验证与底线

这两个坑修完之后，数据应该对得上。我的验证方式是在线对比实验：

• 绿线：AudioWorklet 线程的帧间隔，稳定在 ~2.67ms（128 帧 / 48000Hz）
• 黄线：主线程的 rAF 帧间隔，~16.6ms

两条线各跑各的，SAB 是唯一的通信桥梁。如果绿线稳、黄线稳、数据对齐，就没有坑了。

底层代码没有类型系统保护你。字节和元素搞混，编译器不报错，运行不崩溃，就是数据不对。这种 bug 最毒——你不一定能发现。

这个 bug 是在开发 stw-sentinel 时踩的：
👉 隔离地狱：我用一根红色尖峰，活捉了 V8 的幽灵