MediaRecorder 的 error 事件仅通知录制异常终止，无法恢复数据；应通过 timeslice 分片录制、监听轨道事件预警、错误类型判断及及时清理资源来减少损失。
MediaRecorder 的 error 事件本身**不提供可恢复的录制数据**，也无法直接“补救”已丢失的音视频帧。它只是一个通知机制，用于告知开发者录制流程因底层错误（如编码失败、权限中断、资源耗尽等）而**已终止或即将终止**。所谓“数据补救”，实际是指在错误发生前主动防御、错误发生时及时响应、并尽可能减少数据损失——而非从 error 事件中捞出有效媒体片段。
监听 error 事件并立即停止录制与清理
MediaRecorder 在触发 error 事件后通常进入 inactive 或 ended 状态，继续调用 stop() 可能抛异常或无效。正确做法是：监听后立刻检查状态、安全停止、释放资源。
- 始终为
mediaRecorder.onerror绑定处理函数，避免静默失败 - 在 handler 中先调用
mediaRecorder.state !== 'inactive' && mediaRecorder.stop()，再移除流轨道（stream.getTracks().forEach(t => t.stop())） - 清除
ondataavailable回调中可能残留的Blob引用，防止内存泄漏
在 error 前主动捕获可用数据（关键补救策略）
真正能“补救”的时机不在 error 发生时，而在它发生**之前**。通过设置合理的 timeslice 并持续收集 dataavailable 事件中的 Blob，可确保即使后续出错，已有分片仍可拼接或上传。
- 初始化时传入
{ timeslice: 1000 }（例如每秒触发一次 dataavailable） - 每次
ondataavailable触发，立即将event.data存入数组：recordedChunks.push(event.data) - 即使 error 后只拿到前 3.2 秒的 3 个 Blob，也比最后 stop() 才生成一个大 Blob 更可靠
结合 MediaStreamTrack.onmute / onended 做前置预警
部分 error（如摄像头被占用、麦克风被禁用）会先触发轨道事件，早于 MediaRecorder.error。利用这些信号可提前暂停/重启录制，避免进入 error 状态。
立即学习“前端免费学习笔记（深入）”；
- 对每个 track 绑定
track.onmute = () => console.warn('Track muted — prepare fallback') - 检测到 mute 后，可尝试
track.enabled = true恢复，或提示用户检查设备 - 若
track.readyState === 'ended'，说明流已不可用，应立即停止 recorder 并请求新流
错误类型判断与差异化响应
MediaRecorder.error 事件对象无标准 code 字段，但可通过 event.error.name 和 event.error.message 做粗略归类，采取不同补救动作：
- InvalidStateError：常见于 state 非 'recording' 时调用 stop()，应加 state 判断再操作
-
NotSupportedError：当前 mimeType 不被支持（如 Chrome 不支持 video/webm;codecs="avc1"），需降级为
video/webm或audio/webm - SecurityError：HTTPS 缺失或 getUserMedia 被拒绝，需引导用户切换环境或重试授权
不复杂但容易忽略：error 不是数据丢失的起点，而是防线失守的警报。把“补救”重心放在持续分片、轨道监控和 mimeType 容错上，才能真正守住录制成果。
