如何排查捕获MediaRecorder.ondataavailable中途停止触发的异常

根因定位 #

你复现到的所有现象，本质是浏览器MediaRecorder实现的非标准静默行为，不存在隐藏报错，很多开发者都踩过这个坑：

• 当绑定到MediaRecorder的媒体轨道被直接调用stop()方法终止时，Chromium内核系列浏览器不会主动向上层冒泡轨道的ended事件，也不会同步更新媒体流对象的active状态，更不会给MediaRecorder实例派发error或stop事件。
• MediaRecorder内部的分片采集逻辑会在检测到单轨道终止时静默中断，但自身的state属性不会从recording更新为paused或inactive，直接表现为ondataavailable再也不触发、实例状态却显示仍在运行。
• 你之前绑定的所有流、轨道结束事件未触发，不是你监听代码写错了，是这类浏览器的事件派发规则本身就存在差异：轨道直接调用stop()触发的状态变化，不会经过流对象的事件通道广播。

可靠录制失效检测机制 #

不要仅依赖被动事件监听，需要建立主动校验逻辑：

• 分片超时校验：基于你设置的15s分片间隔，记录每次ondataavailable触发的时间戳，启动30s（2倍分片间隔）的超时定时器，如果超时未收到新的分片回调，直接判定录制失效。这是最不需要额外API、覆盖90%以上静默停更场景的检测逻辑。
• 轨道状态主动巡检：每隔3s遍历所有绑定到MediaRecorder的音视频轨道，检查两个核心指标：
  • 轨道readyState是否为live，只要存在readyState为ended的轨道，立刻判定异常
  • 轨道的muted状态，当轨道持续处于muted状态超过5s，提前预警异常（对应设备被拔出、权限被系统回收的前兆场景）
• 跳过对stream.active字段的依赖：实测验证轨道终止后该字段不会同步更新，无法作为状态判断依据。

异常兜底处理流程 #

• 检测到录制失效后，立即主动调用mediaRecorder.stop()，该操作会强制触发最后一次ondataavailable回调，将内部缓存的所有未导出的Blob分片完整取出，和之前暂存的分片拼接后上传，避免内容丢失。
• 对用户的提示需明确告知：检测到录制设备意外中断，已完整保留此前录制的全部内容，引导用户检查摄像头/麦克风权限、重新开启录制流程。
• 额外补全事件监听覆盖：除了已绑定的轨道onended、流onremovetrack，需补充监听轨道的onmute、onunmute事件，这类事件是浏览器唯一会在轨道异常时主动触发的广播类事件，可靠性远高于流层面的状态监听。

内容的提问来源于stack exchange，提问作者John