在现代 Web 开发中，音视频处理能力的边界正在不断扩展。过去依赖 Flash 或 Silverlight 插件才能实现的录制功能，如今已成为浏览器的原生能力。MediaRecorder API 正是这一变革的核心，它允许开发者直接在浏览器端捕获、编码并保存媒体流，无需任何后端参与。这项技术为在线会议、屏幕分享以及即时视频消息等应用场景提供了坚实的基础。
原生录制的底层逻辑
MediaRecorder 的工作原理并不复杂，但理解其数据流向至关重要。它本质上是一个流媒体转换器。输入端通常是MediaStream对象，这个流可以来自用户的摄像头和麦克风（通过navigator.mediaDevices.getUserMedia获取），也可以来自屏幕捕获（通过getDisplayMedia获取），甚至是 HTML Canvas 元素的实时渲染内容。
一旦媒体流接入 MediaRecorder 实例，浏览器底层的编码器便开始工作。它不会一次性生成一个巨大的视频文件，而是根据设定的时间间隔，连续不断地吐出数据块（Blobs）。这种机制保证了内存的安全性，使得长时间录制成为可能，同时也为实时流媒体传输提供了数据源。开发者需要做的，就是监听这些数据输出事件，将零散的数据块收集起来，最终组装成用户可播放或下载的文件。
W3C 规范指出，MediaRecorder 设计之初就是为了以最小的延迟处理媒体流，同时允许开发者控制编码参数以适应不同的网络环境和存储需求。
MDN Web Docs：https://developer.mozilla.org/zh-CN/docs/Web/API/MediaRecorder_API
完整实现：构建一个屏幕录制工具
理论需要通过代码来验证。下方的示例展示了一个完整的单文件解决方案，它演示了如何获取屏幕画面、录制音频、处理数据块以及最终生成可下载的视频文件。这段代码移除了所有注释，保持了最纯粹的逻辑结构，通过start、stop以及ondataavailable事件的配合，完成从采集到导出的全过程。
<!DOCTYPEhtml><htmllang="en"><head><metacharset="UTF-8"><metaname="viewport"content="width=device-width, initial-scale=1.0"><title>Screen Recorder</title><style>body{font-family:system-ui,sans-serif;display:flex;flex-direction:column;align-items:center;padding:50px;}video{width:80%;max-width:800px;background:#000;margin:20px 0;border-radius:8px;}.btn-group{display:flex;gap:10px;}button{padding:10px 20px;cursor:pointer;}</style></head><body><h1>Native Screen Recorder</h1><videoid="preview"autoplaymutedplaysinline></video><divclass="btn-group"><buttonid="startBtn">Start Recording</button><buttonid="stopBtn"disabled>Stop & Save</button></div><script>letmediaRecorder;letrecordedChunks=[];conststartBtn=document.getElementById('startBtn');conststopBtn=document.getElementById('stopBtn');constpreview=document.getElementById('preview');startBtn.addEventListener('click',async()=>{try{conststream=awaitnavigator.mediaDevices.getDisplayMedia({video:{cursor:"always"},audio:true});preview.srcObject=stream;constoptions=MediaRecorder.isTypeSupported('video/webm; codecs=vp9')?{mimeType:'video/webm; codecs=vp9'}:{mimeType:'video/webm'};mediaRecorder=newMediaRecorder(stream,options);mediaRecorder.ondataavailable=(event)=>{if(event.data.size>0){recordedChunks.push(event.data);}};mediaRecorder.onstop=()=>{constblob=newBlob(recordedChunks,{type:options.mimeType});recordedChunks=[];consturl=URL.createObjectURL(blob);consta=document.createElement('a');a.style.display='none';a.href=url;a.download=`recording_${Date.now()}.webm`;document.body.appendChild(a);a.click();window.URL.revokeObjectURL(url);stream.getTracks().forEach(track=>track.stop());preview.srcObject=null;};mediaRecorder.start(1000);startBtn.disabled=true;stopBtn.disabled=false;}catch(err){console.error(err);}});stopBtn.addEventListener('click',()=>{if(mediaRecorder&&mediaRecorder.state!=='inactive'){mediaRecorder.stop();startBtn.disabled=false;stopBtn.disabled=true;}});</script></body></html>格式碎片化与兼容性挑战
虽然 API 的调用逻辑相对统一，但编码格式的兼容性是开发者必须面对的现实难题。不同的浏览器内核对容器格式和编解码器的支持存在显著差异。Chrome 和 Firefox 倾向于使用 WebM 容器搭配 VP8 或 VP9 编码，这种组合在 Web 环境下表现优异，但生成的视频文件在某些本地播放器或旧版操作系统中可能无法直接打开。
相比之下，Safari 浏览器更青睐 MP4 容器和 H.264 编码。如果你在 Safari 中强制指定video/webm，MediaRecorder 会直接抛出错误。因此，在初始化录制器之前，使用MediaRecorder.isTypeSupported()进行特性检测是不可或缺的步骤。开发者不能假设一种配置就能跑通所有平台，必须编写适应性代码来动态选择最佳的 MIME 类型。
Can I Use (MediaRecorder)：https://caniuse.com/mediarecorder
元数据缺失与时间轴问题
除了格式问题，MediaRecorder 生成的文件还存在一个臭名昭著的缺陷：缺失时长（Duration）元数据。当你使用 Chrome 录制并下载一个 WebM 文件后，你会发现大多数播放器的进度条是失效的，显示的总时长为零或无穷大。这是因为 MediaRecorder 在流式写入数据时，无法预知录制何时结束，因此在文件头中没有写入总时长信息，而在录制结束时，它也不会回过头去修正文件头。
解决这个问题通常需要引入额外的处理步骤。一种常见的做法是使用轻量级的第三方库来解析生成的 Blob，计算实际时长并修补文件头；另一种更为繁重的方案是引入 WebAssembly 版本的 FFmpeg，在浏览器端对视频进行转码。对于追求用户体验的产品而言，这些后期处理虽然增加了复杂性，但却是保证视频文件可用性的必要代价。
媒体录制技术的发展仍在继续，尽管目前仍存在碎片化和细节上的瑕疵，MediaRecorder API 依然是 Web 平台上处理音视频最强大、最直接的工具。掌握它，意味着拥有了脱离服务器限制、直接在客户端生产内容的能力。
