15、MediaStream与Track：轨道生命周期、同步机制、本地与远端流管理

聊到WebRTC的媒体层，MediaStream和Track是绕不开的核心概念。我刚开始接触WebRTC时，总觉得这俩东西就是“拿摄像头→塞进流→发出去”，简单得很。直到有一次做多路视频会议，发现画面不同步、轨道莫名其妙断开、远端流死活显示不出来……嗯，那时候我才意识到，这东西远没我想的那么简单。

说白了，MediaStream是容器，Track是真正的数据生产者。你想想看，一个视频会议里，可能有摄像头画面、屏幕共享、麦克风音频，甚至还有来自虚拟背景处理后的输出——这些都得靠Track来承载，而MediaStream负责把它们打包成一个逻辑单元。

15.1 轨道生命周期：从生到死

每个Track都有自己的生命周期。我个人习惯把它分成四个阶段：获取、激活、静默、结束。

阶段	状态	说明
获取	live + enabled = true	从设备或远端获取到轨道数据
激活	live + enabled = true	轨道正在传输有效数据
静默	live + enabled = false	轨道存活但暂停发送数据
结束	ended	轨道停止，无法恢复

这里有个坑，我曾经踩过：enabled = false 不等于轨道停止。它只是告诉浏览器“别把数据往外发了”，但摄像头灯可能还亮着，麦克风还在收音。如果你真的想释放设备资源，得调用 track.stop()。

// 获取本地摄像头轨道
const stream = await navigator.mediaDevices.getUserMedia({ video: true });
const videoTrack = stream.getVideoTracks()[0];

// 静默轨道（不发送数据，但设备仍占用）
videoTrack.enabled = false;

// 真正停止轨道（释放摄像头）
videoTrack.stop();

15.2 同步机制：同一流的轨道如何对齐

多轨同步是个老生常谈的问题。WebRTC里，同一个MediaStream中的音频和视频轨道，默认是同步的。为什么？因为浏览器底层会给它们打上相同的同步源标识符（SSRC）。

但注意，这只是“同一个流内”的同步。如果你把音频和视频分别放在两个不同的MediaStream里发送，那同步就全靠运气了。我在做远程医疗项目时就遇到过这个问题——医生的口型和声音对不上，患者家属投诉了好几次。

// 正确做法：音频视频放同一个流
const stream = new MediaStream();
const audioTrack = /* 获取音频轨道 */;
const videoTrack = /* 获取视频轨道 */;
stream.addTrack(audioTrack);
stream.addTrack(videoTrack);

// 如果已经分开，可以补救
const sender = pc.getSenders().find(s => s.track === videoTrack);
sender.setStreams(stream); // 重新关联到包含音频的流

15.3 本地流管理：获取、克隆、替换

本地流的管理，说白了就是三个操作：获取、克隆、替换。

获取没什么好说的，getUserMedia一把梭。但要注意权限问题——我见过太多应用在用户拒绝授权后没有做降级处理，直接白屏。

克隆是个好东西。比如你想同时用摄像头做本地预览和录制，直接clone一份轨道就行，不用重新打开设备。

const originalTrack = stream.getVideoTracks()[0];
const clonedTrack = originalTrack.clone();

// 克隆的轨道可以独立控制
clonedTrack.enabled = false; // 不影响原始轨道

替换是WebRTC里非常实用的功能。比如你想切换摄像头，不用重建整个连接，直接replaceTrack就行。

// 切换摄像头
const newStream = await navigator.mediaDevices.getUserMedia({ video: { facingMode: 'environment' } });
const newTrack = newStream.getVideoTracks()[0];

const sender = pc.getSenders().find(s => s.track.kind === 'video');
await sender.replaceTrack(newTrack);

15.4 远端流管理：接收、识别、处理

远端流的管理，核心在于识别。当远端传来多个流时，你怎么知道哪个是摄像头画面，哪个是屏幕共享？

WebRTC没有内置的“流类型”标识。我常用的做法是在信令阶段约定好流ID的命名规则。

// 发送端：给流打标签
const screenStream = await navigator.mediaDevices.getDisplayMedia();
screenStream.id = 'screen-share-' + userId;

const cameraStream = await navigator.mediaDevices.getUserMedia({ video: true });
cameraStream.id = 'camera-' + userId;

// 接收端：根据流ID判断
pc.ontrack = (event) => {
  const stream = event.streams[0];
  if (stream.id.startsWith('screen-share-')) {
    // 显示到屏幕共享区域
  } else if (stream.id.startsWith('camera-')) {
    // 显示到摄像头区域
  }
};

还有一个容易被忽略的点：远端流可能中途变化。比如对方先共享了屏幕，然后又打开了摄像头。这时候你会收到新的ontrack事件，需要动态调整UI布局。

15.5 知识体系总览

下面这张图，是我梳理的MediaStream与Track的核心逻辑。你可以把它当作本章的“地图”。

15.6 避坑指南

最后，分享几个我踩过的坑，希望能帮你少走弯路。

• 不要依赖stream.id做唯一标识——浏览器可能重用ID。我习惯在信令中传一个自定义的userId。
• addTrack和addTransceiver的区别——addTrack会自动创建收发器，但如果你需要精细控制，用addTransceiver更灵活。
• 远端流不一定有video标签——记得检查track.kind，动态创建对应的媒体元素。
• getUserMedia失败时不要直接抛错——给用户一个友好的提示，并提供重试按钮。

---