音视频多轨权限过滤应通过状态机解耦三阶段：prepare只校验缓存权限，bind仅按缓存结果绑定，flush幂等清理资源；权限决策前置固化，各阶段通过显式事件通信。
在音视频多轨权限过滤中，用流程控制解耦多阶段绑定与冲刷，核心是把“什么时候做判断”“什么时候建连接”“什么时候清状态”三件事明确切分，避免混在同一函数里来回跳转或隐式依赖。
用状态机驱动阶段流转，不靠条件嵌套
多轨系统天然存在准备、启用、暂停、恢复、释放等阶段。若用 if-else 堆叠权限校验和轨道操作，极易导致逻辑缠绕、冲刷时机错乱。应定义清晰的状态节点，并让每个节点只做一件事：
- PREPARE 阶段：只加载轨道元信息（如语言、编码格式）、同步检查用户权限、缓存校验结果（如 canUseAudioTrack["zh-CN"] = true）
- BIND 阶段：仅根据 PREPARE 阶段的缓存结果，调用 player.addTrack() 或 video.srcObject = stream，不查权限也不重试
- FLUSH 阶段：只清理当前已绑定的 track 引用、关闭 MediaStream、清除 Map 缓存，不触发新校验、不重走 PREPARE
冲刷（flush）必须无副作用，且可重复执行
冲刷不是“销毁一切”，而是“归还资源到初始就绪态”。常见错误是 flush 时顺手 reload 流、重发鉴权请求，这反而造成耦合。正确做法是让 flush 成为幂等操作：
- track.enabled = false，而非 stop() 或 removeTrack() —— 保留轨道对象，便于后续快速恢复
- 清空本地缓存（如 Map
），但不 touch 播放器内部 pipeline - 若使用 MSE，flush 仅调用 sourceBuffer.abort() 和 URL.revokeObjectURL()，不碰 video 元素本身
权限决策前置固化，绑定与冲刷都不再参与判断
真正解耦的关键，在于把权限从运行时拦截变成配置输入。流程控制只负责“按既定策略执行”，不负责“现场拍板”：
- 所有权限结果（如哪些音轨可用、是否允许后台播放）应在初始化阶段由服务端下发或本地策略引擎一次性计算完成
- 绑定阶段拿到的是 TrackConfig[] 数组，每项含 id、type、enabled（布尔）、priority —— enabled 已是最终决策，无需再 if
- 冲刷时也只遍历该数组，对 enabled=false 的 track 执行静音/禁用，对 enabled=true 的 track 保持原状
用显式事件桥接阶段，避免隐式调用链
不要让 BIND 阶段自动触发 FLUSH，也不要让权限变更直接调用 track.stop()。各阶段之间通过语义明确的事件通信：
- 发出 permission:changed 事件，携带变更的 track ID 列表
- 监听模块收到后，自行决定：对新增许可的 track 调用 bind，对撤销许可的 track 调用 flush（即禁用+缓存清理）
- 整个过程不修改原始 track 对象生命周期，也不要求调用方知道下游如何响应
