addtrack 方法已废弃，应通过 new mediastream([...tracks]) 创建新流并替换 srcobject；需检查轨道 readystate === "live"、克隆复用轨道、避免直接重复使用同一轨道。
addTrack 方法在现代浏览器中已废弃，改用 addTrack 配合 MediaStream 构造器替代
直接调用 MediaStream.addTrack() 添加轨道在 Chrome 78+、Firefox 100+ 中已被弃用，控制台会报 MediaStream.addTrack() is deprecated 警告；实际添加行为可能失效或不触发 addtrack 事件。根本原因是规范转向「不可变流」模型：MediaStream 实例一旦创建，其轨道列表应视为只读，新增轨道需通过新流构造实现。
正确路径是：用 new MediaStream([...existingTracks, newTrack]) 创建新流，再替换旧流（如赋给 srcObject）。
- 不要写
stream.addTrack(track)—— 即使它暂时没报错，也不保证后续帧同步或事件触发 - 若需保留原流中部分轨道（比如只替换音频），先用
stream.getAudioTracks()和stream.getVideoTracks()拆解，再组合 - 替换
srcObject时，浏览器会自动触发重协商（如用于 WebRTC），但不会中断播放，延迟通常在 1–2 帧内
如何安全替换 video.srcObject 并保持画面不闪烁
直接赋值新流可能导致短暂黑屏或尺寸重置，尤其在 Safari 中对 srcObject 变更更敏感。关键不是“怎么加轨道”，而是“怎么换流不被用户感知”。
- 确保新流中至少有一个视频轨道且状态为
readyState === "live"，可用track.enabled = true显式启用 - 替换前缓存原
video.currentTime，替换后立即调用video.play().catch(e => console.warn("play interrupted:", e))，避免因暂停态丢失 - Safari 要求新流必须包含与原流相同类型的轨道（比如原流有视频，新流不能只有音频），否则
srcObject赋值会静默失败 - 可监听
video.oncanplay事件确认新流就绪，而非依赖setTimeout
从 getUserMedia 获取的轨道如何正确复用到新流中
不能直接把 getUserMedia 返回的轨道反复传给多个 MediaStream 构造器——每个轨道只能属于一个流，重复使用会导致 InvalidStateError 或静音。
- 调用
navigator.mediaDevices.getUserMedia({audio: true})后，拿到的MediaStreamTrack对象应立即用于构造第一个流，之后若需复用，必须克隆：track.clone() -
clone()返回新轨道，独立于原轨道生命周期；原轨道关闭（stop()）不影响克隆体 - 注意克隆后的轨道默认
enabled = true，但readyState可能为"ended"（如果原轨道已 stop），需检查并重新 start - WebRTC 场景下，克隆轨道可直接传入
peerConnection.addTrack()，无需额外处理
动态添加轨道时常见的 track.readyState 不一致问题
即使成功构造新流并赋给 srcObject，有时仍看到黑屏或无声，大概率是某条轨道的 readyState 为 "ended" 或 "muted"，而你没检查。
- 在构造新流前，逐个检查每个
MediaStreamTrack的readyState：只接受"live"；若为"ended"，说明已被 stop，无法恢复，必须重新getUserMedia -
muted属性不等于静音状态，它只是控制是否向下游输出；真正影响播放的是enabled（决定是否采集）和readyState（决定是否可用） - 调试时打印
stream.getTracks().map(t => ({id: t.id, kind: t.kind, readyState: t.readyState, enabled: t.enabled}))，比猜更快定位问题
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
