getTracks() 返回一个类数组的 MediaStreamTrack 列表，是同步获取的实时轨道快照，每个元素为 MediaStreamTrack 实例，非 Promise、非字符串、非配置对象。
getTracks() 返回的是什么类型的数据
getTracks() 是 MediaStream 实例上的方法，它返回一个 Array（确切说是 Array-like 的 TrackList），每个元素都是 MediaStreamTrack 实例。不是字符串、不是配置对象，更不是 Promise —— 它是同步返回的实时轨道快照。
常见错误现象：有人用 await stream.getTracks()，结果报错 “stream.getTracks is not a function” 或 “Promise expected”，其实只是因为误以为它是异步方法，或者把 MediaStream 和 MediaDevices.getUserMedia() 混为一谈。
-
getTracks()本身不触发权限请求，也不触发设备采集 —— 它只读取已有流中已激活的轨道 - 返回数组顺序不保证稳定（比如多次调用可能音轨在前或视频在前），不要依赖索引取轨道，应按
kind过滤 - 如果流刚创建但还没 addTrack，数组为空 —— 不代表出错，只是当前无轨道
如何安全遍历并区分音频/视频轨道
直接遍历 getTracks() 返回的列表，检查每个 MediaStreamTrack 的 kind、id、label 和 enabled 状态是最常用做法。注意：label 在非本地流（如远端 RTCPeerConnection 接收的流）中常为空字符串，不能作为唯一标识。
const tracks = stream.getTracks();
tracks.forEach(track => {
console.log({
id: track.id,
kind: track.kind, // "audio" 或 "video"
label: track.label, // 可能为空
enabled: track.enabled, // 是否启用（可被 mute）
muted: track.muted // 是否静音（仅对音频有意义？错 —— video 也有 muted，但语义不同）
});
});
-
track.muted表示该轨道是否被“静音”（音频）或“黑屏”（视频），由应用层控制，和enabled独立 ——enabled=false表示轨道被禁用（不传输），muted=true表示仍在传输但内容被压制 - 同一设备多次调用
getUserMedia可能产生多个同名label的轨道，必须用id做唯一判别 - 某些浏览器（如 Safari）对
label的填充较保守，尤其在 iframe 或非安全上下文中
为什么 getVideoTracks() / getAudioTracks() 比 getTracks() 更常用
虽然 getTracks() 是底层通用接口，但实际开发中几乎总是优先用 getVideoTracks() 和 getAudioTracks() —— 它们返回过滤后的数组，语义清晰、代码意图明确，且避免手动 filter(t => t.kind === 'video') 的冗余。
生成可在 deepbi 沙箱 iframe 内运行或作为独立文件运行的交互式 HTML 页面，使用 `window.deepbi` JS SDK 实现数据查询、空间管理、文件浏览及用户操作。当用户提出以下需求时启用该能力： - 创建 KPI 仪表盘、数据表格、文件浏览器、成员列表、管理页面； - 明确要求“转成 dhtml”、“转译成 HTML”、“把 XX 页面转成……”、“控制台页面”、“管理后台”、“DeepBI 页面迁移”； - 提及位于 `apps/console/src/featur
立即学习“前端免费学习笔记（深入）”；
-
stream.getVideoTracks()返回所有kind === 'video'的MediaStreamTrack，空数组表示无视频轨道 -
stream.getAudioTracks()同理，且在 WebRTC 场景中常用于判断是否收到远端音频（例如：连接建立后检查remoteStream.getAudioTracks().length > 0） - 性能上无差异 —— 这两个方法内部就是对
getTracks()做了简单过滤，没有额外开销 - 兼容性极好，所有支持 MediaStream 的浏览器都实现了这两个方法（包括旧版 Edge）
容易忽略的生命周期问题：轨道可能中途消失
getTracks() 返回的是**当时快照**，不代表轨道会一直存在。比如用户调用 track.stop()、或远端主动 removeTrack、甚至系统资源回收（如后台标签页冻结），都会导致轨道从流中移除 —— 此时再调用 getTracks() 就不再包含它。
- 不要缓存
getTracks()结果长期使用；需要实时信息，就得每次调用 - 监听
stream.onremovetrack事件比轮询更可靠，但注意该事件在 Chrome 中曾长期不触发（已修复），Safari 支持较晚，建议降级为周期性检查getTracks().length变化 - 对
MediaStreamTrack做操作前（如track.enabled = false），先用track.readyState === 'live'判断是否仍有效，否则可能静默失败
最常被跳过的细节是：你以为拿到的 track 还活着，其实它已经被 stop 或脱离流了 —— readyState 和 ended 属性才是唯一可信的状态依据。
