浏览器端 JavaScript 在线录音与 MP3 导出实现指南

简介面向Web前端开发者的一套在线录音方案代码解决在浏览器中实时获取麦克风音频并导出MP3的核心需求适用于在线教育、语音留言、录音笔记等场景。压缩包共6个文件、约58KB包含3个JavaScript文件负责录音控制、实时处理与MP3编码1个HTML页面作为操作入口以及ashx和cs服务端脚本用于接收上传文件。已有949人学习浏览。实现逻辑完整覆盖从浏览器麦克风权限申请到AudioContext构建音频处理图通过MediaStreamAudioSourceNode连接麦克风输入再由ScriptProcessorNode监听音频帧并收集PCM原始数据随后使用ArrayBuffer与Float32Array完成样本读取交由lamejs在Web Worker中编码为MP3最终利用下载属性或异步上传接口保存文件。同时说明了服务端接收逻辑并兼顾桌面与移动端浏览器适配。包内页面、脚本、编码库与服务端示例齐全适合具备JavaScript基础的前端开发者快速搭建网页录音工具亦可作为理解Web Audio API、getUserMedia与AudioContext协作的实战参考。1. 网页录音的起点需求与技术选型先别急着写代码咱们把这事儿捋清楚。你搜“js在线录音录制MP3音频导出代码”大概率是遇到了这类需求在页面上做一个录音功能用户点一下开始说话点一下结束然后把录音生成一个 MP3 文件下载到本地或者上传到服务器。这个场景在在线客服、语音备注、消息回复、语音评测类项目里非常常见。先说结论浏览器原生能力录不出 MP3 文件。这是很多新手第一次踩坑的地方——以为MediaRecorder直接指定audio/mp3就能导出结果在 Chrome 里一跑发现要么报错要么导出的是webm或者ogg格式。原因很简单MP3 编码是有专利的虽然专利已过期但浏览器厂商出于各种考量普遍没有内置 MP3 编码器。Chrome 里实测支持格式通常是webm;codecsopus和audio/webmSafari 能录audio/mp4Firefox 能录audio/ogg。所以想让输出文件是 MP3必须在拿到原始音频数据后自己用 JS 做一次编码。那怎么做有两条主流路线路线一用MediaRecorder录制浏览器原生支持的格式再把音频解码成 PCM最后交给 MP3 编码器编码。这个方案多了一次转码而且解码和编码都得在前端完成性能开销大不说代码复杂度也高。路线二直接用getUserMedia拿麦克风音频流接入Web Audio API采集原始 PCM 数据然后通过lamejsLAME 编码器的 JavaScript 移植版把 PCM 编码成 MP3。这个方案链路短、效率高直接绕开了MediaRecorder的格式限制也是目前社区里比较主流的做法。我下面要分享的方案就是路线二。整体代码量不大核心依赖只有一个lamejs加上浏览器原生的getUserMedia和AudioContext就能实现从录音到 MP3 导出的完整闭环。提示lamejs有维护不太活跃的问题业界还有breezystack/lamejs这类 fork 版本修复了部分 bug。我用原版做示例但生产环境建议使用维护更好的 fork基础 API 基本一致。2. 核心依赖与前置准备这一节先把每个环节用到的 API 和依赖讲透后边直接看代码就不会晕。2.1 麦克风权限获取录音的第一步是拿到麦克风的音轨用的是navigator.mediaDevices.getUserMedia它是一个返回 Promise 的异步 API必须在 HTTPS 或 localhost 环境下运行否则浏览器会拒绝调用。async function initMicrophone() { if (!navigator.mediaDevices || !navigator.mediaDevices.getUserMedia) { throw new Error(当前浏览器不支持录音功能请使用新版 Chrome、Edge 或 Firefox); } const stream await navigator.mediaDevices.getUserMedia({ audio: { echoCancellation: true, // 开启回声消除 noiseSuppression: true, // 开启降噪 autoGainControl: true // 自动增益 } }); return stream; }这三项音频处理配置建议全开。回声消除在录音场景里尤其重要如果你的页面里有扬声器在播放提示音不开回声消除麦克风会把扬声器的声音一起录进去导致回放时全是回声。而且这属于系统级的处理比后期写代码消除效果要好得多。2.2 lamejs前端 MP3 编码器lamejs的工作机制简单说就是把 LAME 编码器一个开源的 MP3 编码库几乎所有的 MP3 编码软件底层都是它编译成 JavaScript/WASM让我们能在浏览器里直接用 JS 调用 MP3 编码逻辑。引入方式有两种!-- CDN 引入 -- script srchttps://cdn.jsdelivr.net/npm/lamejs1.2.1/lame.min.js/script !-- 或者 npm 安装 -- npm install lamejs如果你用 npm 安装需要留意一点原版lamejs的main入口走的是 CommonJS在 Vite 这类 ESM 环境下引入会报错。建议直接改成import { Mp3Encoder } from lamejs或者使用 fork 版本这里先不多展开后边的常见问题部分会细说。lamejs 里最核心的类是Mp3Encoder实例化时需要传入三个参数声道数、采样率、比特率。const mp3Encoder new lamejs.Mp3Encoder(1, sampleRate, 128); // 参数含义单声道、采样率如 44100、比特率 128kbps这个sampleRate必须与AudioContext的采样率保持一致否则会出现音频时长错乱、音调变高等问题这个坑后边我会单独讲。2.3 录音需要的基础 HTML 结构为了让示例直接能跑我先把整个页面的骨架写出来!DOCTYPE html html langzh-CN head meta charsetUTF-8 title在线录音 MP3 导出/title /head body button idstartBtn开始录音/button button idstopBtn disabled停止并导出 MP3/button audio idplayer controls/audio a iddownloadLink styledisplay:none下载 MP3 文件/a script srchttps://cdn.jsdelivr.net/npm/lamejs1.2.1/lame.min.js/script script // 核心逻辑后边逐步展开 /script /body /html我习惯把“停止录音”和“导出 MP3”合并成一个动作简化用户操作路径——点停止一起生成文件。如果你有“先停止、再预览、最后手动导出”的需求也可以把导出拆成独立按钮逻辑不变。3. 录音核心实现PCM 采集与 MP3 编码现在进入正题。整个实现链路是麦克风流 → AudioContext 解码 → ScriptProcessorNode 采集 PCM → lamejs 编码 → Blob 导出。3.1 创建音频数据处理链AudioContext是 Web Audio API 的核心负责管理音频处理图。我们用createMediaStreamSource把麦克风流接入音频处理图再用ScriptProcessorNode也可以选 AudioWorklet后边会讲差异监听音频数据回调let audioContext, source, processor, mediaStream; let pcmData []; async function startRecording() { mediaStream await initMicrophone(); audioContext new (window.AudioContext || window.webkitAudioContext)(); source audioContext.createMediaStreamSource(mediaStream); // 4096 是缓冲区大小数值越小延迟越低、回调越频繁 processor audioContext.createScriptProcessor(4096, 1, 1); // 处理音频数据 processor.onaudioprocess (event) { const inputBuffer event.inputBuffer; const channelData inputBuffer.getChannelData(0); // getChannelData 返回 Float32Array值域 [-1, 1] // 这里先拷贝一份再存避免后续被内部复用导致数据错乱 pcmData.push(new Float32Array(channelData)); }; // 连接音频处理链 source.connect(processor); processor.connect(audioContext.destination); }几个很容易忽略的细节getChannelData返回的数组是 AudioBuffer 内部存储的引用不是拷贝。如果不new Float32Array(channelData)深拷贝一下后边获取到的数据可能已经被新数据覆盖最终导出文件时长对、内容却是乱的。这一点特别坑我第一次做的时候就因为省了这个拷贝导出的 MP3 全是“电流声”一样的杂音。processor.connect(audioContext.destination)这一步不能省。如果不把processor连接到destinationonaudioprocess根本不会被触发。也许你会想“我又不播放连什么 destination”但ScriptProcessorNode的设计就是这样——必须连接输出端才有数据流。我把echoCancellation、noiseSuppression等设置放在了getUserMedia的配置里这套系统级处理比任何 JS 层面的降噪方案都稳定可靠。注意ScriptProcessorNode官方已标记为 deprecated推荐用AudioWorklet替代。但AudioWorklet需要额外加载worklet模块文件配置成本高不少而ScriptProcessorNode在主流浏览器上仍然能正常工作。个人录音工具、内部系统这类对兼容性要求不极端的场景用ScriptProcessorNode是完全可行的。如果你追求未来兼容性可以自己搜一下“AudioWorklet recorder”原理相似。3.2 PCM 数据转 MP3录音结束后pcmData里存了一堆Float32Array每个元素的值域是 [-1, 1]代表采样点的振幅。但 lamejs 的encodeBuffer方法接收的是16-bit 整数 PCM 数据值域是 [-32768, 32767]所以要先做一次类型转换function encodeMP3(audioContext, pcmData) { const sampleRate audioContext.sampleRate; const mp3Encoder new lamejs.Mp3Encoder(1, sampleRate, 128); // 把 Float32Array 拼接成一个大数组 const totalLength pcmData.reduce((sum, chunk) sum chunk.length, 0); const pcmFloat32 new Float32Array(totalLength); let offset 0; for (const chunk of pcmData) { pcmFloat32.set(chunk, offset); offset chunk.length; } // 转成 16-bit PCM const pcmInt16 new Int16Array(totalLength); for (let i 0; i pcmFloat32.length; i) { let sample pcmFloat32[i] * 32767; // 把 [-1, 1] 映射到整数范围 sample Math.max(-32768, Math.min(32767, sample)); // 钳制防止溢出 pcmInt16[i] sample; } // 分块编码 const mp3Chunks []; const blockSize 1152; // lamejs 内部帧大小按这个尺寸切块最稳定 for (let i 0; i pcmInt16.length; i blockSize) { const chunk pcmInt16.subarray(i, i blockSize); const encoded mp3Encoder.encodeBuffer(chunk); if (encoded.length 0) { mp3Chunks.push(new Uint8Array(encoded)); } } // 收尾flush 用于刷新编码器内部缓冲区 const end mp3Encoder.flush(); if (end.length 0) { mp3Chunks.push(new Uint8Array(end)); } // 合并所有 Uint8Array const totalBytes mp3Chunks.reduce((sum, chunk) sum chunk.length, 0); const mp3Blob new Blob(mp3Chunks, { type: audio/mp3 }); return mp3Blob; }这里解释几个关键决策为什么做钳制Float32Array在极少数情况下可能因为回声消除算法等处理出现超出 [-1, 1] 的异常值。不钳制的话乘以 32767 后可能超过Int16Array范围出现溢出回绕听到的结果就是噪声爆音。编码为什么要分块lamejs的encodeBuffer每帧处理 1152 个采样点。传一个超长数组进去它内部会循环处理但内部缓冲可能不够容易出问题。按 1152 块大小切片是社区里经过大量验证的稳妥做法。因为 MP3 属于有损压缩每个编码帧是一块独立数据切片编码后再拼接对整个文件没有任何影响。为什么最后要调一次flush()编码器内部通常有残留数据还没输出flush()的作用就是把缓冲区清空补齐完整的 MP3 帧。不调用它导出的文件很可能缺结尾数据播放到最后一秒会突然中断。3.3 导出下载从 Blob 到 MP3 文件编码完成后拿到一个Blob对象它本质上就是 MP3 文件的二进制内容接下来只需要触发浏览器下载function triggerDownload(mp3Blob, filename recording.mp3) { // 创建本地对象 URL const url URL.createObjectURL(mp3Blob); // 预览 const player document.getElementById(player); player.src url; // 下载 const downloadLink document.getElementById(downloadLink); downloadLink.href url; downloadLink.download filename; downloadLink.style.display inline-block; // 释放对象 URL setTimeout(() URL.revokeObjectURL(url), 10000); }这一步有一个很容易被忽视的细节URL.createObjectURL创建的对象 URL 是有生命周期的页面关闭前需要手动释放否则会占用内存。我一般是在用户停止录音、点击下载后延迟一段时间再revokeObjectURL。如果提前释放下载会莫名其妙地失败。别问我是怎么知道的问就是被虐过。停止录音时还需要清理掉一切占用资源function stopRecording() { processor.disconnect(); source.disconnect(); audioContext.close(); mediaStream.getTracks().forEach(track track.stop()); const mp3Blob encodeMP3(audioContext, pcmData); triggerDownload(mp3Blob); // 重置状态准备下一次录音 pcmData []; }mediaStream.getTracks().forEach(track track.stop())至关重要。不主动停止麦克风轨浏览器会一直显示“正在使用麦克风”的图标而且麦克风一直处于占用状态。用户如果在你这个页面录完音又去开一个视频会议会发现麦克风被占用了——这就是忘记停止音轨导致的。4. 常见问题排查与避坑指南这一节是我个人实操中最常踩的坑也是社区里被问得最多的问题逐条整理给大家。4.1 麦克风获取失败或权限拒绝这个问题的现象是getUserMedia的 Promise 直接 reject报错信息常见的有NotAllowedError、NotFoundError、NotReadableError。错误类型可能原因处理方向NotAllowedError用户拒绝授权或之前点过“禁止”提示用户手动点击浏览器地址栏的摄像头/麦克风图标重新授权NotFoundError设备上没有可用的音频输入设备插上麦克风或耳机再试NotReadableError麦克风已被其他应用程序占用关闭占用麦克风的软件尤其是会议软件和直播软件SecurityError页面不是 HTTPS 或 localhost部署到 HTTPS 环境本地开发使用 localhost有一个相对隐蔽的问题用户第一次点了“允许”后浏览器会记住授权状态但不会因为页面刷新就自动解除。如果用户中途在系统层面关闭了麦克风权限getUserMedia会继续返回已过期的 stream录音出来的声音全是静音。所以建议每次录音前都重新调用一次getUserMedia不要缓存 stream 复用。4.2 导出的 MP3 播放时长与实际不符这是一类特别常见又特别隐蔽的问题。录了 30 秒导出的 MP3 播放出来却只有 20 秒或者反过来声音变快、音调变高。原因几乎都是lamejs 输入的采样率跟 AudioContext 的采样率不一致。比如你的AudioContext经过浏览器自动降级实际采样率是48000但你写死了44100传给Mp3Encoder。lamejs 内部按照44100的格式打包 MP3 帧头信息而数据本身是按48000采的——播放器按44100去解析时长和音调自然就全乱了。解决方案是每次动态读取audioContext.sampleRateconst mp3Encoder new lamejs.Mp3Encoder(1, audioContext.sampleRate, 128);另外要注意开发调试时控制台命名的“音频设备默认采样率”可能不是设备实际值。建议在页面打印出audioContext.sampleRate对比确认。4.3lamejs引入报错在Vite项目中直接import lamejs from lamejs大概率会报lamejs is not defined或模块导出异常。原因是原版lamejs打包方式比较老旧用 UMD 格式且默认导出在module.exports上挂了一个mp3encoder方法。最简单的处理方式是直接通过 CDN 引入或者用 npm 包breezystack/lamejs这个 fork 修复了原版的不少编码 bug原版有部分音质问题即便正常使用也可能偶尔出现杂音。如果是自己封装 npm 项目还有一个经验优先 import 具体的类而不是整个命名空间。import { Mp3Encoder } from breezystack/lamejs;4.4 录音数据二次处理与多段拼接如果你不满足于“录一段导出一段”想把多段录音拼接成一个 MP3这里有个简单技巧PCM 数据直接拼接再一次性编码。因为 PCM 是纯采样数据没有格式头拼接起来完全无损。// 把所有录音的 PCM 数据拼到一起 let combinedPCM new Float32Array(totalLength); // 依次拷贝每段录音数据 // 最后一次性交给 encodeMP3 处理但如果你录的是 MP3 文件就直接拼接二进制就不行了因为每个 MP3 文件都有 ID3 标签和帧头信息直接拼接会导致播放器解析错乱。正确做法是解码成 PCM 再拼接或者用专门的音频处理库处理这超出了本文范围不过有需求的可以顺着这个方向去查。4.5 录制过程中出现爆音、卡顿这个问题在这几年移动设备上尤其明显。排查重点有二回调频率太高。createScriptProcessor的缓冲区大小设成 4096在低端手机上仍可能因为回调太频繁造成卡顿。可尝试提高到 8192牺牲少量延迟换取稳定性。页面主线程阻塞。如果录音过程中有大量 DOM 操作、大数据渲染任务会导致音频回调丢失数据产生断音。尽量把录音和其他重逻辑分开处理例如把编码操作放到requestIdleCallback或 Web Worker 中。Web Worker 方案可以这么做把采集到的 PCM 数据postMessage给 WorkerWorker 内部跑 lamejs 编码最后再把 MP3 Blob 传回主线程。这样即使编码再耗时也不会卡住页面 UI。代码量会增加一些但如果做的是正式产品这一步必要度还是很高的。5. 实际操作心得与扩展思路最后聊一点我在实际开发中的体会。这套方案我最初是在一个在线面试系统里实现的。候选人需要录制一段自我介绍然后上传到服务器面试官后边收听。当时遇到一个很实际的问题录音文件太大太占磁盘。如果直接录wav格式一分钟大约 10MB 左右服务器压力很大转成 MP3 后一分钟只有 1MB 上下压缩率非常可观这就是为什么“MP3 导出”这个需求会反复出现在各类产品中。还有一个容易被忽略的点录音前要做麦克风音量检测。用户点了“开始录音”但麦克风是坏的或者音量被调到最低录了整整两分钟后才发现导出的 MP3 是无声的体验极其糟糕。建议在录音前用getByteFrequencyData检测一下底噪小于某个阈值就给出提示“未检测到声音请检查麦克风”。另外导出的文件名最好加上时间戳避免用户连续录制后下载一堆同名recording.mp3导致浏览器自动改名成recording (1).mp3。我一般用这种格式const filename recording_${Date.now()}.mp3;还是用new Date().toISOString().replace(/[:.]/g, -)生成可读性更强的名字看团队习惯。最后再分享一个小技巧录制过程中实时展示音量波形图。做法是在onaudioprocess里拿一块 PCM 数据的振幅做平方根均值更新到一个canvas或简单的 CSS 条形动画上。实现成本很低但用户体验提升非常明显——用户知道自己“确实在录音”而不是对着静默页面产生疑惑。“这个功能怎么没反应”的反馈能少掉一大半。如果你后续还想扩展上传到服务器用FormData把 Blob 直接 append 进去就行转wav的话给 PCM 数据手动加一个 44 字节的 WAV 文件头就行想做 Web Worker 方案把Mp3Encoder独立封装成一个通信模块即可。传统做法没有太多绕路的地方先跑通最简版本再逐步叠加能力会更稳妥。本文还有配套的精品资源点击获取