requestdata() 仅在需中途预览/上传片段或防stop()末尾丢数时使用；调用前须确保recorder.state为"recording"、mediastream轨道活跃、且start()后已过首帧渲染周期。
requestData() 什么时候该用、什么时候不该用
requestData() 的作用是强制 MediaRecorder 输出当前已缓冲但尚未触发 dataavailable 的数据块，它不是“暂停并保存”，也不是“导出中间结果”的万能键。真实场景中，它只在两种情况下必要：一是录制中途需要预览/上传片段（如直播切片），二是防止调用 stop() 后末尾几秒数据丢失。但多数人误以为它能“实时取流”，结果发现 dataavailable 没触发、event.data 是空 Blob——本质是流还没产出第一帧，或录制器状态不对。
调用前必须确认的三个状态
直接 recorder.requestData() 报错或静默失败，大概率是因为以下任一条件不满足：
-
recorder.state必须是"recording"；若为"inactive"或"paused"，会抛InvalidStateError - 底层
MediaStream的轨道必须活跃：检查stream.getAudioTracks().length > 0（音频）或stream.getVideoTracks().length > 0（视频），否则流无数据可录 - 不能在
start()后立刻调用——尤其对canvas.captureStream()创建的流，首帧渲染完成前调用无效；建议等至少一个requestAnimationFrame周期后再试
requestData() + dataavailable 的典型配合写法
关键不是“怎么调”，而是“怎么接”。requestData() 触发后，仍靠 recorder.ondataavailable 回收数据，且每次只返回一个 Blob，和 stop() 触发时行为一致。示例逻辑如下：
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
recorder.ondataavailable = (event) => {
if (event.data.size > 0) {
chunks.push(event.data);
// 可在此处上传 chunk，或生成临时 URL 预览
}
};
// 录制中某时刻主动取一段
recorder.requestData(); // 不要 await，它同步触发事件
// 后续 stop() 仍需调用，否则流不终止
recorder.stop();
注意：requestData() 不重置内部缓冲区，后续数据仍会累积，直到 stop() 或再次 requestData()。多次调用不会导致重复数据，但频繁调用（如每 100ms 一次）可能因浏览器调度延迟，实际输出间隔远大于预期。
移动端和 Safari 的现实限制
Android Chrome 和桌面 Edge 支持稳定，但 iOS Safari（即使 16.4+）对 requestData() 行为不一致：有时触发 dataavailable，有时完全静默，且不报错。更麻烦的是，部分安卓 WebView（如微信内置）压根不实现该方法，typeof recorder.requestData === "undefined"。因此，依赖 requestData() 做分段逻辑时，必须做存在性判断：
if (typeof recorder.requestData === "function") {
recorder.requestData();
} else {
// 降级方案：仅靠 stop() 获取完整 Blob，或改用定时 canvas.toBlob() 截图合成
}
真正容易被忽略的点是：即便 requestData() 成功触发了事件，拿到的 Blob 也**不含完整时间戳元数据**，无法直接拼接成连续视频——它只是编码器当前缓冲区快照，帧边界可能不齐。要做无缝分段，得依赖服务端或 ffmpeg.wasm 做二次对齐。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
