WebRTC中如何通过await等待ICE候选收集完成？

浏览器原生没有直接提供pc.onIceCandidateComplete()这类可直接await的方法，但基于标准事件封装一个仅几行代码的工具函数即可实现需求，不需要引入额外依赖。

可直接复用的实现 #

首先封装通用的等待函数，自带超时兜底避免流程卡死：

/**
 * 等待RTCPeerConnection的ICE候选收集完成
 * @param {RTCPeerConnection} pc 对等连接实例
 * @param {number} timeout 超时时间，单位毫秒，默认10秒
 * @returns {Promise<void>}
 */
function waitForIceGatheringComplete(pc, timeout = 10000) {
  return new Promise((resolve) => {
    // 已经处于收集完成状态直接返回
    if (pc.iceGatheringState === 'complete') return resolve();

    const timer = setTimeout(() => {
      cleanup();
      // 超时直接返回，使用已收集到的候选即可，不影响后续连接
      resolve();
    }, timeout);

    const onStateChange = () => {
      if (pc.iceGatheringState === 'complete') {
        cleanup();
        resolve();
      }
    };

    const cleanup = () => {
      clearTimeout(timer);
      pc.removeEventListener('icegatheringstatechange', onStateChange);
    };

    pc.addEventListener('icegatheringstatechange', onStateChange);
  });
}

你的业务代码可以直接改成这样：

const pc = new RTCPeerConnection(configuration);
const sendChannel = pc.createDataChannel("sendChannel");
const offer = await pc.createOffer();
await pc.setLocalDescription(offer);

// 等待ICE候选收集完成
await waitForIceGatheringComplete(pc);

// 注意：必须从pc.localDescription取最新的SDP，不要直接用createOffer返回的offer对象
// 收集到的ICE候选会自动追加到pc.localDescription的sdp字段中
send(pc.localDescription);

为什么原生没有直接提供这个方法 #

核心原因是WebRTC标准设计层面并不鼓励等所有ICE候选收集完成再发送SDP的模式：

• 标准默认推荐**Trickle ICE（涓流ICE）**流程：每收集到一个ICE候选就立刻通过信令发送给对端，不需要等全部收集完，这种模式能把连接建立耗时从数秒压缩到数百毫秒，用户体验更好。如果原生提供await等待收集完成的便捷方法，会变相鼓励开发者用效率更低的全量SDP发送模式。
• ICE候选收集受网络环境影响极大，可能出现长时间卡收集状态的情况，直接提供无兜底的await方法很容易让开发者写出无超时、流程永久卡死的代码，把封装逻辑交给开发者可以更灵活地适配业务场景的超时、降级策略。

其他等价实现 #

除了监听icegatheringstatechange事件，也可以通过监听icecandidate事件判断收集完成：当事件回调的candidate属性为null时，就代表所有候选已经收集完毕，代码如下：

function waitForIceComplete(pc) {
  return new Promise((resolve) => {
    if (pc.iceGatheringState === 'complete') return resolve();
    pc.addEventListener('icecandidate', (e) => {
      if (e.candidate === null) resolve();
    });
  });
}

两种写法效果完全等价，优先推荐用icegatheringstatechange的方案，语义更清晰。

注意事项 #

• 不要混淆iceGatheringState和iceConnectionState：前者标记候选收集进度，后者标记ICE连接连通状态，监听错事件会导致逻辑异常。
• 生产环境一定要加超时：不要无限等待ICE收集完成，通常3-10秒的超时足够收集到大部分可用候选，超时后直接发送当前已有的SDP即可，剩余候选可以后续通过Trickle方式补发，不会影响连接建立。
• 如果你的信令服务支持，优先用Trickle ICE模式，不要等全量候选收集完再发，能大幅提升连接速度。

内容的提问来源于stack exchange，提问作者Kivylius