MDN中getUserMedia录制示例计时结束后未停止音视频硬件占用

嘿，我太懂你说的这个情况了——那个MDN的录制示例手动点「停止录制」时一切正常，但等计时到了自动停止后，摄像头还亮着、麦克风也还在被占用，就像后台还在偷偷录制似的对吧？其实问题根源很简单：自动停止的逻辑里只终止了录制进程，却没主动释放媒体流的轨道资源。

核心原因拆解 #

当你调用mediaRecorder.stop()时，只是告诉浏览器“停止把媒体流编码成录制文件”，但生成录制内容的MediaStream本身还处于活跃状态，它包含的音频、视频轨道（Track）仍然在占用硬件设备。浏览器只会在轨道被主动调用停止方法时，才会释放摄像头/麦克风的占用权限。

具体修复步骤 #

你只需要在计时结束的回调函数里，补上释放轨道的代码就行。假设原示例里的定时器逻辑是这样的：

// 原代码：仅停止录制，未释放硬件资源
setTimeout(() => {
  mediaRecorder.stop();
}, recordTime);

把它修改成下面这样，就能让自动停止时同时关闭音视频设备：

setTimeout(() => {
  mediaRecorder.stop();
  // 遍历并停止所有音视频轨道，释放硬件
  stream.getTracks().forEach(track => {
    track.stop();
  });
  // 可选但推荐：清理视频元素的源，避免内存泄漏
  if (window.recordVideoElement) {
    window.recordVideoElement.srcObject = null;
  }
}, recordTime);

为什么这能解决问题？ #

• stream.getTracks()会返回当前媒体流里的所有轨道（包括音频轨道和视频轨道）
• 每个轨道调用track.stop()后，浏览器会立即断开与硬件的连接，摄像头指示灯会熄灭，麦克风也不再处于占用状态
• 清理视频元素的srcObject是为了断开视频预览与媒体流的关联，防止不必要的内存占用

你可以对比下手动停止按钮的逻辑——原示例里的停止按钮点击事件应该已经包含了轨道停止的代码，所以手动操作没问题，只是自动计时的分支漏掉了这关键一步而已。

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