插件解析音频数据陷入死循环导致页面卡死

[tanjwGit]

[tanjwGit]

从扩展自身的角度来修复，核心问题有两个：拦截方式阻塞了 send() 调用链，以及对原始二进制数据做了病态的递归解析。分别有对应的思路：

---

一、拦截方式：从「同步阻塞」改为「异步旁路」

当前扩展的实现（伪代码）大致是：

const _originalSend = WebSocket.prototype.send;
WebSocket.prototype.send = function(data) {
  parseAndLog(data);            // ← 同步解析，阻塞调用方
  _originalSend.call(this, data);
};

正确的做法是先放行，再解析：

const _originalSend = WebSocket.prototype.send;
WebSocket.prototype.send = function(data) {
  _originalSend.call(this, data);         // ① 立即调用原始 send，不阻塞
  
  const copy = data instanceof ArrayBuffer 
    ? data.slice(0)                        // ② 拷贝一份（send 后 buffer 可能被 transfer）
    : data;
  
  requestIdleCallback(() => {              // ③ 空闲时再解析
    parseAndLog(copy);
  });
};

或者更彻底——把解析扔到 Worker：

WebSocket.prototype.send = function(data) {
  _originalSend.call(this, data);
  
  const copy = data instanceof ArrayBuffer ? data.slice(0) : data;
  parserWorker.postMessage({ id: msgId++, data: copy }, 
    copy instanceof ArrayBuffer ? [copy] : []);  // transfer 给 Worker，零开销
};

这样无论解析多慢，都不会阻塞主线程和 ws.send() 调用方。

---

二、解析逻辑：避免对 bytes 字段做递归解析

当前扩展的通用 protobuf 解码器遇到 wire type 2（length-delimited）时，会无条件尝试递归解析为子消息。对于 bytes data = 5 这种装着原始 PCM 音频的字段，这是灾难性的。

修复策略 1：限制递归深度 + 字段号上限

function decodeMessage(buf, offset, end, depth = 0) {
  if (depth > 8) return { _raw: buf.slice(offset, end) };  // 递归过深，放弃
  
  while (offset < end) {
    const [tag, newOffset] = readVarint(buf, offset);
    const fieldNumber = tag >>> 3;
    const wireType = tag & 7;
    
    if (fieldNumber > 50000) {       // 正常 proto 不会有这么大的字段号
      return { _raw: buf.slice(offset, end) };  // 判定为原始二进制
    }
    
    if (wireType === 2) {
      const [len, dataOffset] = readVarint(buf, newOffset);
      // 尝试解析为子消息，失败则回退为原始 bytes
      try {
        fields[fieldNumber] = decodeMessage(buf, dataOffset, dataOffset + len, depth + 1);
      } catch {
        fields[fieldNumber] = buf.slice(dataOffset, dataOffset + len);
      }
    }
    // ...
  }
}

修复策略 2：启发式判断「这是不是结构化数据」

在递归解析子消息之前，先快速扫描判断内容是否像合法的 protobuf：

function looksLikeProtobuf(buf, offset, end) {
  let validFields = 0;
  let pos = offset;
  while (pos < end && validFields < 5) {
    const [tag, next] = readVarint(buf, pos);
    const fieldNum = tag >>> 3;
    const wireType = tag & 7;
    
    if (wireType > 5 || fieldNum === 0 || fieldNum > 10000) return false;
    validFields++;
    pos = skipField(buf, next, wireType);  // 快速跳过字段值
    if (pos < 0) return false;             // 解析失败
  }
  return validFields >= 2;  // 至少有 2 个看起来合法的字段
}

只有通过启发式检查的 length-delimited 字段才递归解析，否则直接当 raw bytes 展示。

修复策略 3：超时保护

function safeParse(buf) {
  const start = performance.now();
  return decodeWithTimeout(buf, 0, buf.length, () => {
    if (performance.now() - start > 5) {   // 超过 5ms 就放弃
      throw new Error('parse timeout');
    }
  });
}

---

三、懒解析：捕获时不解析，查看时才解析

最符合 DevTools 扩展使用场景的方式——用户不会盯着每一帧看：

// 捕获时：只存原始数据
WebSocket.prototype.send = function(data) {
  _originalSend.call(this, data);
  messageLog.push({
    timestamp: Date.now(),
    direction: 'send',
    raw: data instanceof ArrayBuffer ? data.slice(0) : data,
    parsed: null,  // 延迟解析
  });
};

// 用户在面板中点击某条消息时才解析
function onMessageClick(entry) {
  if (!entry.parsed) {
    entry.parsed = safeParse(entry.raw);  // 按需解析，带超时保护
  }
  renderDetail(entry.parsed);
}

---

总结

修复层面	思路	效果
拦截方式	先 send 再异步解析 / Worker 解析	消除主线程阻塞
解析逻辑	递归深度限制 + 字段号上限 + 启发式判断	避免对 raw bytes 做病态递归
解析时机	懒解析，捕获时只存 raw data	彻底零开销捕获

最佳组合：拦截时先放行 + 懒解析 + 超时保护。这样即使面对大量二进制 WebSocket 流量，对页面性能也是零影响。