很多做 WebRTC 开发的朋友，早期都会遇到同一个困惑： getUserMedia 拿到的到底是个什么东西？为什么有时候叫它 MediaStream ，有时候又看见代码里在操作 MediaStreamTrack ？面试的时候被问“Track 和 Stream 的区别”，脑子里能浮现出概念，真到写代码、排查线上问题的时候，又经常被这两者的边界搞混。

我在做视频会议和直播连麦相关的项目时，踩过不少这方面的坑。比如本地预览好好的，推流上麦之后远端就是黑屏；再比如切换摄像头，画面死活切不过去；还有更隐蔽的，轨道明明已经结束了，但远端还挂着一条“僵尸流”。这些问题追根溯源，本质上都是对 Track 与 Stream 的关系理解不够透彻。

这篇文章不打算讲枯燥的规范条文，而是从实际项目的视角，把 WebRTC 里这两个最基础、也最容易被人忽略的概念掰开揉碎讲清楚，顺便把我在实战中积累的注意事项、排查思路一并整理出来。如果你是刚入门 WebRTC 的开发者，或者已经写了段时间但还是对底层逻辑一知半解，这篇文章应该能帮你省下不少瞎琢磨的时间。

1. 从一次翻车经历说起：Stream 与 Track 的核心概念拆解

先讲个我自己的翻车案例。当时在做一个在线教育产品的 1v1 课堂，老师端需要同时推摄像头画面和屏幕共享画面。我最初的理解是：一路视频就是一个 Stream，所以很自然地创建了两个 MediaStream ，一个放摄像头，一个放屏幕。本地预览一切正常，但学生端偶尔会出现画面串台的情况——明明切到了屏幕共享，学生看到的却还是摄像头画面，或者两个画面来回跳。

后来定位到最后，问题就出在我对 Track 和 Stream 边界的理解太粗糙了。

1.1 先搞清楚 Stream（MediaStream）到底是什么

MediaStream 这个词，中文通常翻译成“媒体流”。直观理解，它就像是一个 媒体轨道容器 。这个容器本身不产生任何数据，它只负责把一组相关的 MediaStreamTrack 组织在一起，对外提供一个统一的、可操作的单位。

举个例子。你在做视频通话的时候，本地摄像头采集画面，麦克风采集声音。画面和声音是两路独立的数据源，但它们都属于“本地的这个用户”。你当然可以把它们拆成两个 Stream 分开传输，但更自然的做法是放进同一个 Stream 里，通过一次 addStream 或逐条 addTrack 操作，把这路视频和音频打包成一个整体，远端拿到这个 Stream 之后，再分别消费里面的画面和声音。

这里面有一个关键点要记住： Stream 本身没有任何媒体数据，它只是一个逻辑上的分组 。哪怕里面只有一条音频轨，没有视频轨，它仍然是一个合法的 Stream；哪怕里面一条轨都没有，它作为一个对象也依然可以存在。只不过在 WebRTC 的实际传输中，空的 Stream 没有多大意义。

1.2 再把 Track（MediaStreamTrack）单独拎出来看

MediaStreamTrack 才是真正承载媒体数据的实体。它代表 一路独立的、单一的媒体源数据 。比如：

• 一个摄像头的画面，是一条 Track；
• 一个麦克风的声音，是一条 Track；
• 一个屏幕共享的画面，是一条 Track；
• 一个 Canvas 实时录制的画面，也是一条 Track。

每一个 Track 都有自己的状态机。比如 readyState 有两个取值： live 代表正在实时产生数据， ended 代表数据源已经终止。Track 还支持 enabled 和 muted 属性，用来控制这路数据的开关状态。

这里需要重点理解的是：Track 才是你真正要在网络上传输的“数据列车”，Stream 只是给这些列车编组、打标签的“调度站”。 getUserMedia 返回给你的那个 Stream 对象，本质上就是一次获取到的所有 Track 的集合。

1.3 两者的关系：容器与内容，一对一还是多对多

为了把关系理清楚，我画过一张非常简单的对照图（文字版）：

维度	MediaStream（Stream）	MediaStreamTrack（Track）
本质	容器/逻辑分组	数据实体
数据能力	不产生数据	持有真实媒体数据
状态	无终端状态概念	有 live/ended 等状态
可包含	可包含多条 Track	不可包含其他对象
传输作用	便于统一管理和协商	真正被编解码和传输

从数量关系上看，一个 Stream 可以包含多个 Track，这是最常见的情况。但反过来，一个 Track 能不能同时属于多个 Stream？规范上是可以的——同一个 MediaStreamTrack 对象可以被加入到多个 MediaStream 容器中。不过在实际业务中，这种情况不太常用，也不是推荐的做法，因为会让接收端的逻辑变得混乱。

注意：规范意义上的 Track 与 Stream 关系，不是简单的“一对一”，而是“一对多”和“多对一”的组合关系。你完全可以只用一个 Stream 承载摄像头画面和麦克风声音，也完全可以把摄像头画面同时加入两条 Stream 分别用于本地预览和远端推流。

理解到这层之后，我们再回头看那个翻车案例。我当时的错误在于：把“一路画面源”等同于“一个 Stream”，并且在媒体协商后，对远端 ontrack 回调里拿到的 Track 做了不恰当的关联操作，导致学生端在多个 Stream 之间切换时逻辑错乱。后来改成“只用一个 Stream 承载一路画面，切换画面时替换 Stream 内部的 Track”，问题就消失了。

2. 为什么必须理解 Track 的生命周期：一切状态异常都源于此

先说结论：在 WebRTC 的实践中，把注意力从 Stream 转移到 Track 上来，往往能让很多“莫名其妙”的问题变得清晰可见。

刚接触 WebRTC 的人普遍有一个误区：把 MediaStream 当作一个“可以暂停/恢复/结束”的媒体单元。但实际上，媒体单元是 Track，Stream 不具备这样的能力。当你调用 track.stop() 的时候，真正终止的是这条轨道的数据采集；当远端的人挂断电话时，你这边 ontrack 收到的轨道状态变化，也是发生在 Track 层面。

2.1 Track 的几个关键生命周期状态

一个标准的 MediaStreamTrack 生命周期，大致是这样的：

1. 初始状态 ： readyState 为 live ，数据源正在持续产生数据。
2. 运行中 ： enabled 和 muted 可以动态切换。比如把 enabled 设为 false ，视频轨会输出黑帧，音频轨会输出静音数据，但轨道本身还没有结束。
3. 结束状态 ： readyState 变为 ended ，此时轨道不会再产生任何数据。触发 ended 的原因包括：直接调用了 track.stop() 、摄像头被拔掉、麦克风权限被撤销、或者远端连接关闭。

这里要特别理解 enabled = false 和 stop() 的区别。很多人以为把 enabled 设为 false 就能达到“关闭本端摄像头”的效果，实际上它只是让这一路的媒体内容变成“空数据”，用黑屏或静音来填充。网络传输仍然在继续，编解码资源仍然在消耗，只是数据内容变了。而 stop() 是彻底终结这条轨道，停止采集，释放硬件资源。

在实际项目中，这两个操作对应着完全不同的业务含义：

• 想实现“暂时关闭摄像头，但保持连接不断开”——用 track.enabled = false ，远端会看到黑屏，但连接是健康的。
• 想实现“退出房间，释放摄像头权限”——必须调用 track.stop() 。

2.2 替换 Track 与删除 Track 的正确姿势

在视频会议里最常见的需求之一，就是动态切换摄像头——从前置切到后置，或者从摄像头切到屏幕共享。很多初学者用最粗暴的方式：重新 getUserMedia 拿到新 Stream，然后整个替换掉旧的 Stream，再走一遍 negotiation 。这样做不是不行，但会产生两个问题：

• 重新获取媒体设备需要时间，画面会短暂中断；
• 直接替换整个 Stream 会导致远端 onremovetrack 和 ontrack 重新触发，接收端的 DOM 元素要重新绑定，播放会出现闪烁。

更优雅的方式是： 在原 Track 上做替换 。核心思路是，通过 track.applyConstraints() 修改 Track 的约束（比如 deviceId ），让它重新绑定到一个新的采集设备上。这种方式不需要重新协商，也不会断开传输，画面可以做到无缝切换。

比如这段代码，切换前后摄像头只需要修改 deviceId 就能完成：

async function switchCamera(deviceId) {
  const stream = localStream;
  const videoTrack = stream.getVideoTracks()[0];
  await videoTrack.applyConstraints({
    deviceId: { exact: deviceId }
  });
  // 轨道还是同一条轨道，远端不需要任何操作，画面已经切换
}

去设备列表里找出前后摄的 deviceId ，动态调用 applyConstraints 即可。注意这里面的 exact 约束：如果设备不存在，会直接抛错，所以最好先用 getCapabilities() 确认一下。

但需要提醒的是， applyConstraints 只适用于“同一个物理设备属性和能力范围”内的切换，比如调整分辨率、帧率、码率，或者切换同一个摄像头品牌下的不同模式。如果是跨类型的切换（比如从摄像头画面切到屏幕共享），这种方案就不适用了。屏幕共享产生的是一条全新的、不同来源的 Track，它跟摄像头 Track 没有任何关联。这时候就必须用下面的方案：

// 先加新轨道
pc.addTrack(screenTrack, localStream);
// 再把旧轨道从发送端移除
pc.removeTrack(sender);

这种“先加后移”的顺序很有讲究。如果先 removeTrack 再 addTrack ，中间会有一个空窗期，远端可能因为接收不到任何视频而短暂黑屏。先加后移，则可以让新轨道的数据先到，再移除旧的，远端看到的是流畅的画面切换。

2.3 Stream 在其中的角色：只是一个“挂靠单位”

说了这么多，Stream 在这个过程中到底扮演什么角色？答案是：它只是帮你把 Track 组织起来的一个单位，远程端在接收时可以通过 streams 属性拿到 Track 所属的 Stream 列表。但真正决定“推不推流”“推什么内容”的，是 Track 本身。

所以我的建议是，在代码层面别太把 Stream 当回事。你的业务逻辑如果围绕 MediaStreamTrack 来设计，写出来的代码会清晰得多。比如管理本端媒体的时候，可以直接维护一个 Map ：

const localTracks = new Map();
localTracks.set('camera', cameraTrack);
localTracks.set('microphone', micTrack);
localTracks.set('screen', screenTrack);

需要推流的时候，把 Track 逐条 addTrack 到 RTCPeerConnection 上。远端在 ontrack 里拿到 Track 之后，再根据 Track 的 kind 和 id 去区分它是视频还是音频，是摄像头还是屏幕。

实操心得：不要依赖 Stream 的标签去判断媒体内容。Tracker 的 id 在设计项目时应该自己加业务前缀，比如 camera-xxx 、 screen-xxx ，这样远端处理起来会非常简单。否则纯靠系统生成的随机 id，排查问题时很难一眼看出这条轨道是干嘛的。

3. 代码实操：从本地采集到远端渲染的完整链路

前面讲了概念，下面结合代码把整条链路串一遍。我以一个简单的“两人视频通话”为例，展示从本地采集、本地预览、媒体协商，到远端渲染的完整流程，边写边标注每一步在操作 Track 还是 Stream。

3.1 第一步：getUserMedia 返回的到底是什么

const stream = await navigator.mediaDevices.getUserMedia({
  video: { width: 1280, height: 720 },
  audio: true
});
console.log(stream instanceof MediaStream); // true
console.log(stream.getTracks()); // [MediaStreamTrack, MediaStreamTrack]
console.log(stream.getVideoTracks()[0] instanceof MediaStreamTrack); // true

拿到这个 stream 对象之后，常见的操作有两种：

• stream.getVideoTracks() / stream.getAudioTracks() —— 分别取视频轨和音频轨；
• stream.getTracks() —— 一次性取所有轨道。

本地预览时，把 Stream 对象直接丢给 <video> 元素即可：

const videoElement = document.getElementById('localVideo');
videoElement.srcObject = stream;

srcObject 接收的是一个 MediaStream ，浏览器内部会自动消费里面所有视频轨道。注意这里不能直接传 Track，否则元素是渲染不出画面的。

3.2 第二步：addTrack 与 addStream 的选型

把本地媒体加到 RTCPeerConnection 上，有两种写法：

// 写法一：addStream（已不推荐）
pc.addStream(stream);

// 写法二：addTrack（推荐）
stream.getTracks().forEach(track => {
  pc.addTrack(track, stream);
});

addStream 在老代码里很常见，它在内部其实就是“把 Stream 里所有 Track 都 add 一遍”，但当你需要单独控制某一条轨道的增删时，这种整包式的 API 就不好使了。更关键的是， addTrack 的第二个参数（Stream）是可选的，而且传不传会影响 SDP 协商结果。

实际开发中我一直推荐用 addTrack + 显式传 Stream 的组合，原因有两点：

1. 后续做轨道级操作（动态加屏幕、移除旧轨道）时， sender 的指向是明确的。
2. 传了 Stream 之后，SDP 里会带上 a=msid 信息，方便远端把收到的 Track 关联到对应的 Stream 上，业务层可以更灵活地组织多路流。

3.3 第三步：远端 ontrack 的正确写法

远端接收的代码，要围绕 ontrack 事件来写：

pc.ontrack = (event) => {
  const track = event.track;
  const stream = event.streams[0]; // 注意：streams 是一个数组

  // 远端视频容器
  const remoteVideo = document.getElementById('remoteVideo');

  if (track.kind === 'video') {
    if (remoteVideo.srcObject !== stream) {
      remoteVideo.srcObject = stream;
    }
  }

  track.onended = () => {
    // 远端轨道结束时的收尾工作
    console.log('Remote track ended:', track.id);
  };
};

这里有几个比较容易踩的坑。

第一个坑： event.streams 可能是一个空数组。如果本端在调用 addTrack 时没有传 Stream，那么远端 ontrack 里的 event.streams 就是空的。此时如果你用 event.streams[0] 去赋值 srcObject ，会拿到 undefined ，画面渲染不出来。解决办法是提前判断：

if (event.streams && event.streams[0]) {
  remoteVideo.srcObject = event.streams[0];
} else {
  // 手动创建一个新的 MediaStream
  const stream = new MediaStream([event.track]);
  remoteVideo.srcObject = stream;
}

第二个坑：多路视频（比如摄像头 + 屏幕共享）同时到达时， ontrack 会被触发多次。如果每一路都直接覆盖 remoteVideo.srcObject ，那就会出现两个画面互相挤兑的情况。正确姿势是，根据 track.id 或 track.kind 路由到不同的视频容器里。

3.4 第四步：断线重连与轨道清理

通话结束或者掉线重连时，需要显式清理本地轨道和接收端的资源：

function cleanup() {
  // 遍历所有发送器
  pc.getSenders().forEach(sender => {
    if (sender.track) {
      sender.track.stop();
    }
  });
  // 移除所有远端轨道
  pc.getReceivers().forEach(receiver => {
    if (receiver.track) {
      receiver.track.stop();
    }
  });
  pc.close();
}

一条 Track 在两端各有一个执行上下文。本端 track.stop() 可以彻底停止采集，但远端那条 Track 通常不会立刻变成 ended ，而是会等网络层信号（比如 BYE）到达后，或者 pc.close() 之后，才会触发 ended 状态变化。所以远端清理要放在 onremovetrack 或 ontrack 的 onended 回调里面统一处理。

4. 在 SDP 与网络传输的层面看 Track 与 Stream：协商的本质

搞定本地代码之后，大部分人就觉得完事了。但一旦你开始优化弱网表现、排查多路流串音、或者想搞明白为什么明明加了轨道但对面收不到，就必须往 SDP 和传输层面再看一眼。这里藏着 Track 与 Stream 的另外一面。

4.1 m-line 与 Track 的映射关系

在 WebRTC 的 SDP（会话描述协议）中，媒体轨道的存在形式是 m-line 。一条 m-line 代表一路媒体流，它包含编码参数、端口、传输地址等信息，并且在 ssrc 层面与 Track 一一对应。当你调用 addTrack 添加一条摄像头视频轨时，底层其实就是在 SDP 里添加了一条视频 m-line ，同时生成了对应的 SSRC （同步源标识）。

这个 SSRC 在网络传输中是一个非常关键的标识。远端网卡收到 RTP 数据包时，就是通过 SSRC 来区分这一路数据属于哪条 Track 的。两条视频轨如果 SSRC 冲突，接收端就会疯狂丢包、花屏。好在现代浏览器底层会处理冲突检测，但作为开发者，你要理解这个映射关系的存在，才能在分析问题时知道该去哪里查数据。

4.2 Stream 在 SDP 中的体现：msid 的故事

如果只有 Track，没有 Stream，那 SDP 协议完全能工作——每个 m-line 都有独立的 SSRC，传输没有任何问题。但为了上层业务方便（比如把多个 Track 划分到同一个逻辑分组），WebRTC 引入了 MSID 机制，也就是在 SDP 的 a=msid 属性里，标记这条 Track 归属于哪个 Stream。

a=msid:8a0e2f1c-34d2-4e91-9b1f-2c7e0b3b3f2e 6a5d2f1c-98b3-4c2e-9d8a-3f6e1d2a4b5c

这个属性的格式是：第一个值是 Stream ID，第二个值是 Track ID。WebRTC 内部把这两个 ID 分别对应到 MediaStream.id 和 MediaStreamTrack.id 。远端浏览器解析到 msid 之后，会自动做好 Track 到 Stream 的映射，然后按分组关系触发 ontrack 事件。

所以 Stream 在网络层面的作用不是“承载数据”，而是“给轨道分组做标记”。 这也是为什么远端 ontrack 的 event.streams 是一个数组——同一路 Track 可能被标记为属于多个 Stream，虽然浏览器端这种情况很少见，但协议层面是支持的。

4.3 重新协商：什么时候必须重谈，什么时候不用

对于 Track 和 Stream 的不理解，最容易引发的问题就是：到底什么时候需要重新协商（也就是再次调用 setLocalDescription + setRemoteDescription 交换 SDP）？

我的经验总结如下：

操作类型	是否需要重新协商	原因
Track 的 enabled/muted 切换	不需要	不改变媒体协议和编码，只是数据内容变化
Track 的 applyConstraints 调整分辨率	通常不需要	编码参数实时协商，通过 RTP 头中的扩展位通知远端
只改 Stream 的分组（不增删 Track）	不需要	SDP 中 m-line 没有变化
新增一条 Track（addTrack）	需要	新 Track 需要新 m-line，必须重新协商
移除一条 Track（removeTrack）	需要	对应的 m-line 要从 SDP 中移除
第一次建立连接前的初始设置	需要	初始协商

缩小到业务层面，最常见的操作就两个：新增屏幕共享需要重新协商，结束屏幕共享也需要重新协商。这也是我在做协作工具时经常提醒同事的：不要因为加了轨道不重协商，就对端永远收不到；也不要因为切换了摄像头就惊慌失措地重协商，白白增加网络开销。

注意：在重新协商期间，已存在的 Track 不会中断传输。新增的 Track 会在协商完成后才开始发送数据。原有的旧轨在协商完成前会继续按原来的参数发送，这就保证了切换过程中不出现长时间的黑屏或花屏。

5. WebRTC 中 Track 与 Stream 的高频问题排查实录

这一节，我把开发过程中遇到过的、跟 Track 与 Stream 强相关的问题做一个排查总结。这些问题在搜索引擎里出现的频率非常高，很多关键词甚至比 WebRTC 本身还热，比如什么 “stream disconnected before completion”，虽然那是服务端流式接口的报错，但很多前端同学一开始分不清，把它跟 WebRTC 媒体流混为一谈，这里我也顺带澄清一下。

5.1 场景一：本地有画面，远端黑屏

这个问题出现频率极高，排查路径一般是这样：

1. 确认 pc.getSenders() 里到底有没有 Track，里面那条 track 是不是 live 状态；
2. 确认 SDP 协商是否正常完成， signalingState 是否为 stable ；
3. 确认 ontrack 是否触发，远端是否收到了 Track；
4. 确认远端是否把 srcObject 正确赋值到了 <video> 元素上。

从 Track 与 Stream 的角度来看，最典型的原因有两个：

第一个原因是 addTrack 时没传 Stream 参数，远端 ontrack 里用了 event.streams[0] ，结果拿到 undefined 。这个前面已经提到过，不再赘述。

第二个原因是 Track 被 enabled = false 了 。有时候为了做本地预览的“关闭摄像头”效果，直接 videoTrack.enabled = false ，然后把这条 Track 也推了出去。远端当然会黑屏——它收到的是黑帧数据，并不是连接出问题了。这种情况需要区分好“主动静音、主动黑屏”和“传输故障”的区别。

5.2 场景二：切换摄像头之后，远端没反应

切摄像头最推荐的方式是 applyConstraints 修改 deviceId ，这种情况下远端不需要任何干预，画面自然切换。如果用的方案是重新获取 Stream 再 replaceTrack ，那要注意 replaceTrack 是 RTCRtpSender 上的方法：

const sender = pc.getSenders().find(s => s.track.kind === 'video');
const newStream = await navigator.mediaDevices.getUserMedia({ video: { deviceId } });
const newTrack = newStream.getVideoTracks()[0];
await sender.replaceTrack(newTrack);

replaceTrack 的好处是，它内部会自动处理 SDP 的协商流程，你不需要手动调用重新协商。在 WebRTC 的演进中， replaceTrack 几乎成了“轨道级替换”的标准方案，因为它在底层已经优化过了，切换延迟非常低。

但要特别注意： replaceTrack 替换后，旧 Track 如果你不再需要， 必须手动 stop() ，否则摄像头指示灯会一直亮着。这是很多开发者会忽略的一步。此外，如果你在 getUserMedia 里指定了 deviceId ，而且旧设备和新设备是同一个物理设备的不同模式，浏览器可能直接忽略切换，这时候先释放旧 Track 再重新采集反而更快。

5.3 场景三：onremovetrack 一直触发，远端画面闪断

这个问题往往和 Track 的周期管理有关。如果一个 Stream 中包含了多路 Track，而你频繁地 removeTrack ，或者对同一个 Track 多次调用 stop() ，就可能导致远端 onremovetrack 多次触发。每次触发都会让 srcObject 发生一次重绑定，表现为闪烁或短暂黑屏。

解决办法分两步：

• 减少不必要的 removeTrack 调用。如果只是静音，用 enabled = false ，不要移除轨道；
• 接收端做防抖处理。在 onremovetrack 里不要立即清空 srcObject ，而是先确认这个 Track 是否还有替代轨道可用，如果有，保留旧的 Stream 画面直到新轨道到位。

5.4 场景四：多路流场景下，Stream 分组错乱

在主播连麦、多级转发的场景下，经常会遇到多个 Stream 同时到达的情况。这时候如果处理逻辑没有按好 ID 区分，很容易把主讲人的视频渲染到某个听众的容器里。

我的做法是：在业务层约定一套 Track ID 规范。比如摄像头视频轨的 ID 为 camera-{userId} ，屏幕共享轨的 ID 为 screen-{userId} ，麦克风音频轨的 ID 为 mic-{userId} 。这样远端在 ontrack 里拿到 Track 之后，可以第一时间根据 ID 路由到正确的容器，而不是依赖 Stream 的顺序或者假设 event.streams 唯一。

5.5 特别注意：不要把服务端 SSE/HTTP 流水关键词与 WebRTC 媒体流混淆

在热搜词里出现了一大堆如 “stream disconnected before completion: stream closed before response.completed” 之类的报错，这里要专门提醒一下。这类信息来自服务端的流式响应（比如 SSE、HTTP chunked、AI 对话流式接口），和 WebRTC 的 Track/Stream 是完全两个不同的技术栈。

• WebRTC 的 Stream 是 MediaStream ，内部是 RTP 包流；
• 服务端的 stream 是 HTTP/SSE 的数据流，是给客户端按块读取的文本或二进制数据。

如果你在做 WebRTC 项目时看到了那一堆 “stream disconnected” 报错，大概率不是 WebRTC 本身的问题，而是你的信令服务器或某个数据接口挂了。排查思路完全不同：WebRTC 除了媒体流之外，还有一条独立的信令通道（通常用 WebSocket），这条通道如果断流，才会导致信令异常。别把两套流程混在一次查。

6. 最终实践建议：把 Stream 当“信封”，把 Track 当“内容”

最后，我想结合个人的开发体验，给读者几条比较实在的建议。

第一， 在你的业务代码里，时刻清晰回答一个问题：我这一行代码操作的是容器还是数据？ 如果操作的是数据内容，比如编解码、渲染、静音、关闭采集，那你应该找 Track；如果只是想把几路数据打个包、归个类，那你才需要操作 Stream。这个思维习惯能帮你省掉大量排查时间。

第二， 强烈建议你使用 addTrack 而不是 addStream 。 虽然两套 API 现在都能用，但 addTrack 能给你更细粒度的控制和更明确的 sender 对象。项目越复杂，这种细粒度的好处就越明显。

第三， 跨端互操作时，尽量少依赖浏览器自动的 Stream 分组能力。 因为不同浏览器对 msid 的处理有一些细节差异，可能导致 Track 与 Stream 的映射在不同端上表现不一致。你们团队自己约定的 Track ID 规范和业务层路由逻辑，才是可控的。

第四， 不要把 “stream disconnected” 类报错和 WebRTC 媒体流画上等号。 报错里的 stream 大概率是后端数据流，不是媒体流。出问题时先定位是哪一层，再决定从哪个技术栈里找答案。

WebRTC 本身并不复杂，复杂的是当所有概念都混在一起、在同一个事件循环里互相纠缠时的现场。Track 与 Stream 就像操作系统里的文件和文件描述符——区分度清晰了，写起来就会顺手很多。希望这篇内容能帮你把这两个核心概念彻底揉碎、吸收掉，让你在写 WebRTC 代码的时候能更胸有成竹一些。