听感上的「慢半拍」和「自己的声音被返回来」，通常不是同一处故障。回声多半出在终端侧：扬声器发出的声音被麦克风重新收进去、系统开着麦克风监听、耳机自带耳返。延迟则可能落在终端音频管线、浏览器实现、上行链路、服务端处理中的任意一段。可行的顺序是先把两条链路拆开：用耳机与外放的对照确认回声来源，用 Web Audio 的时间戳把「慢」变成可比较的毫秒区间，再去网络侧看抖动与恢复点，最后才决定要不要换设备或换浏览器。

适用场景：使用实时语音对话时觉得回话慢、能听到自己的声音返回。操作动作：先用耳机与外放各做一轮对照，再用 AudioContext.currentTime 记录采集到播放的时间差，重复多轮取中位数，同时记录上行帧间隔与恢复点。验证方式：外放换成耳机后回声消失，说明是扬声器被麦克风重收；时间差区间稳定，说明不是偶发抖动。风险边界：单次测量只能定位大方向，跨地域链路和蓝牙耳机的固有延迟属于环境限制，难以靠配置消除。

用耳机和外放各做一轮，确认回声来源

同一台设备、同一个浏览器、同一个房间，只改音频输出方式，其余条件不动。两种方式各说同一句话，比如十秒左右的连续朗读，边听边记录三件事：有没有听到自己的声音返回、返回是贴着说话立刻出现还是延后一段、延迟感是否随输出方式变化。

• 外放一轮：明显听到自己的声音被返回来，先怀疑扬声器发出的声音被麦克风重新收进去，而不是先怀疑链路。
• 耳机一轮：换成有线或蓝牙耳机，重复同一句话。回声消失或明显减轻，基本可认定回声来自外放回授。
• 耳机仍有回声：需要看耳机自身的耳返、系统声音设置里的麦克风监听、以及浏览器或系统的回声消除是否被关掉。可以先在系统设置里关闭麦克风监听再重复一轮。

判断规则很直接：回声随外放消失，问题在终端拾音与放音的耦合；回声与输出方式无关，则更可能是软件侧的参考信号处理或对方侧的回授。需要留意蓝牙耳机本身会额外引入一段音频延迟，这一轮只用来判断回声来源，不要拿它给延迟下结论。

用 Web Audio 时间戳记录采集到播放的时间差

目标是拿到「本地开口」到「本地听到回话」之间的时间差，把它变成可重复比较的毫秒数。思路是在同一个 AudioContext 里记录两个时间点：麦克风首次检测到语音能量的 currentTime，以及远端音频开始播放时的 currentTime。下面的骨架可以放在独立测试页或控制台里执行，选择器和阈值按自己的环境替换。

const ctx = new AudioContext();
await ctx.resume();

const capture = [];   // 采集起点
const playback = [];  // 播放起点

// 采集侧：麦克风能量超过阈值即记录；这里刻意关掉 AEC，方便第 1 节对照
const mic = await navigator.mediaDevices.getUserMedia({
  audio: { echoCancellation: false, noiseSuppression: false }
});
const micSrc = ctx.createMediaStreamSource(mic);

// AudioWorklet 更稳，这里用 ScriptProcessor 说明记录位置
const sp = ctx.createScriptProcessor(1024, 1, 1);
sp.onaudioprocess = (e) => {
  const buf = e.inputBuffer.getChannelData(0);
  let sum = 0;
  for (let i = 0; i < buf.length; i++) sum += buf[i] * buf[i];
  const rms = Math.sqrt(sum / buf.length);
  if (rms > 0.02 && capture.length < 20) {
    capture.push({ ctxTime: ctx.currentTime, wall: performance.now() });
  }
};
micSrc.connect(sp);
sp.connect(ctx.destination);

// 播放侧：远端音频开始播放时记录，并读取输出时间戳做校正
function attachRemote(mediaStream) {
  const el = new Audio();
  el.srcObject = mediaStream;
  el.onplaying = () => {
    const ts = ctx.getOutputTimestamp ? ctx.getOutputTimestamp() : {};
    playback.push({
      ctxTime: ctx.currentTime,
      wall: performance.now(),
      outCtxTime: ts.contextTime,
      outPerfTime: ts.performanceTime
    });
  };
  el.play();
}

每一轮只取「开口时刻」，也就是 capture 数组里的第一个样本，与本次回话的 playback 第一个样本相减：(playback[0].ctxTime - capture[0].ctxTime) * 1000，得到毫秒值。建议同一句话重复 5 到 10 轮，剔除第一轮（通常包含握手和缓冲建立），其余值排序后取中位数，中位数比平均值更不容易被单次卡顿带偏。

const median = (arr) => {
  const s = [...arr].sort((a, b) => a - b);
  const m = Math.floor(s.length / 2);
  return s.length % 2 ? s[m] : (s[m - 1] + s[m]) / 2;
};

const deltas = rounds.map(r => (r.playCtx - r.capCtx) * 1000);
console.log(median(deltas), deltas);

这个差值包含采集、编码、上行、服务端处理、下行、解码和播放缓冲的总和，因此不能单独归因到网络。它的价值在于两点：同一环境下多次测量，看数值区间是否稳定；换设备或换浏览器后，看中位数是否明显移位。测完记得把 echoCancellation 恢复为默认，关闭它只是为了让第 1 节的回声对照更容易被听见。

在网络面板观察上行抖动与恢复点

需要盯住两项指标：一是上行消息的发送间隔抖动，二是出现停顿之后的恢复点。如果链路走 WebSocket，打开浏览器开发者工具的 Network 面板，选中对应的 ws 连接，在帧列表里能看到每一帧的时间，把连续上行帧的时间差列出来，间隔忽长忽短就是抖动。如果链路的音频走 WebRTC，Network 面板通常看不到音频包，应改用 chrome://webrtc-internals 或应用自身的统计接口，看 outbound-rtp 的发送量、remote-inbound-rtp 的 jitter 与 roundTripTime，以及 inbound-rtp 的 jitterBufferDelay 和 packetsLost。

时间标记方式：测试时用第 2 节的脚本在本地打点，每次开口和每次听到回话都记一次 performance.now()，同时记下当时的帧序号或统计快照时间。停止测试后，把「听感明显慢」的那几次时间点，与帧间隔出现空档、jitter 抬升或 jitterBufferDelay 增大的时间点放在同一条时间轴上比对。慢的时刻总是落在发送前的空档（本地帧还没发出去），重点看终端和上行；发送节奏正常、只在接收侧出现堆积和恢复点，重点看下行与服务端返回节奏。

换设备与浏览器各测一遍

变量控制：同一网络接入、同一位置、同一句测试语音、同一服务入口，测试期间关闭其他占用带宽和音频设备的程序，第 2 节的测量脚本保持不变。组合方式按「设备 × 浏览器」交叉，例如设备 A 配浏览器一、设备 A 配浏览器二、设备 B 配浏览器一、设备 B 配浏览器二，每种组合至少完成两次完整轮次。

• 同一浏览器、换设备后中位数明显移位：偏向终端侧，重点查声卡驱动、系统音频增强、蓝牙设备模式。
• 同一设备、换浏览器后中位数明显移位：偏向浏览器实现，重点查音频管线差异、扩展插件、页面是否被后台节流。
• 换设备和换浏览器都没有明显变化：偏向链路或服务端，回到第 3 节的统计里找证据。

结论不一致时的处理：两次结果差异很大，先不要合并取平均，而是检查这两次之间有没有别的变量变了，比如中途换了耳机、后台在下载、切了网络频段。把变化项记下来重跑一轮；只有在条件一致的前提下，中位数的移动才有参考价值。

列出先修哪一处、哪些改不了

按成本和确定性排序，先修能立刻验证的：

1. 先做耳机与外放对照，确认回声是否为外放回授；是的话改用耳机，或把麦克风与扬声器拉开距离。
2. 关闭系统里的麦克风监听和音频增强，检查是否装了虚拟声卡或音频路由类软件。
3. 用第 2 节的脚本在同一浏览器复测，确认时间差区间是否稳定；不稳定再去看第 3 节。
4. 换浏览器、禁用音频相关扩展后再测一轮。
5. 最后才考虑更换网络接入方式或频段，这一项需要结合具体环境确认。

属于环境限制、反复折腾也难以消除的项目包括：跨地域链路的基础往返时间、蓝牙耳机编解码带来的固定延迟、设备端音频驱动的缓冲下限、服务端处理与返回节奏、房间混响与背景噪声。这些环节可以优化，但很难靠本地配置压到接近零。

可接受的替代做法：把长段连续说话拆成短句，缩短单次拾音窗口；用按键说话或临时静音控制拾音时段；对延迟敏感的操作改用文本输入；回声无法消除时，在本地关闭监听并优先使用耳机，避免把外放回授当成链路故障反复排查。