简介：围绕H5音频采集与上传场景整理的示例包，面向需要实现浏览器调用麦克风、获取实时音频流、录音并提交后台的前端开发者。内容聚焦Web Audio API与MediaRecorder的配合，涉及音频流接入、录音分块、Blob合并和服务端接收等环节，适合有JavaScript基础、希望搭建PC端音频交互原型的读者参考。压缩包共9个文件，约189KB，含3个JavaScript脚本、2个HTML页面、1个MP3音频、1个C#源码、1个ASHX处理程序及1张PNG示意图，分别对应前端逻辑、页面演示、音频素材、后台处理与流程说明。已有7409人学习，反映出语音识别、在线通话和实时音频处理等场景的持续关注。读者可据此梳理从麦克风授权、实时流处理到录音上传的完整链路，结合页面与脚本示例理解各模块职责，并借助服务端代码把握前后端联调思路。包体轻便，适合作为H5录音功能入门样例，也能为项目中音频采集与上传模块提供结构借鉴。
1. 从一次“录到了但没声”的排查说起：PC 端麦克风采集与录音上传的最小闭环
前端调用麦克风获取实时音频流和录音上传，看起来是最简单的需求，实际最先翻车：页面点下录音，进度条在走，回放却是静音；或者本地能听，传到后台变成 0 字节。核心不是一句 getUserMedia，而是权限、设备、编码、分段、上传五段链路都对齐。这套示例围绕 H5 音频采集和 PC 端音频输入，把 MediaStream、MediaRecorder、Blob 组装、分片上传和排错点串成可复现的流程，适合正在做语音录入、客服质检、在线面试录音的前端开发直接拆改。
2. 把权限和设备拿稳：PC 端音频采集的约束、枚举与轨道参数
2.1 先枚举还是先申请权限：deviceId、label 与 devicechange 的时序
在 PC 端做音频输入，第一反应是enumerateDevices()列设备，但页面刚打开时多数浏览器不会给完整设备标签，deviceId也可能为空。原因是设备枚举受权限门控：没有拿到麦克风授权前，浏览器只告诉你“有输入设备”，不告诉你具体是哪一个。常见做法是先由用户点击触发getUserMedia({ audio: true })拿到授权，再调用enumerateDevices()刷新列表；用户切换设备时，用deviceId: { exact }重新开流，而不是在旧流上改约束。这个顺序弄反，下拉框会出现空 label、重复 deviceId，后续切设备必然踩坑。
async function listAudioInputs() { const devices = await navigator.mediaDevices.enumerateDevices(); return devices .filter((device) => device.kind === 'audioinput') .map((device, index) => ({ deviceId: device.deviceId, label: device.label || `麦克风 ${index + 1}` })); } // 设备热插拔时刷新列表，不要直接重开录音 navigator.mediaDevices.addEventListener('devicechange', async () => { const inputs = await listAudioInputs(); console.log('当前可用麦克风', inputs); });这段代码只做两件事：授权后刷新设备列表、监听设备变化。deviceId是浏览器会话内的设备标识，不是永久硬件 ID，拔插 USB 耳麦后可能变化；label在未授权时通常为空，所以不要用 label 做唯一键。devicechange只建议更新下拉框，不要在录音过程中自动切流，否则旧录音的MediaRecorder会跟着旧MediaStream一起失效。
PC 端音频输入的麻烦在于设备不是固定的：笔记本内置麦克风、USB 耳麦、扩展坞音频口可能同时存在，用户还会中途拔插。我的习惯是把设备选择做成“先授权、再枚举、再重开流”的三步，录音过程中不允许切设备；要切就停当前录音、落盘、再开新录音。这样虽然多一次用户操作，但不会出现半段音频挂在旧MediaStream上的问题。
2.2 约束对象怎么写：回声消除、降噪、自动增益与采样率的取舍
getUserMedia的audio约束不是写得越细越好。录音质检、语音识别这类场景，通常希望保留原始声，回声消除、降噪、自动增益反而会改变频谱；通话、会议场景则相反，压制环境噪声和回声更重要。采样率也一样，写exact: 16000遇到只支持 44.1kHz 或 48kHz 的 USB 麦克风会直接报OverconstrainedError，写ideal: 48000让浏览器回退更稳。
| 约束 | 录音/质检场景 | 通话/会议场景 | 说明 |
|---|---|---|---|
echoCancellation | false | true | 录音保留原始声，通话压回声 |
noiseSuppression | false | true | 降噪会削掉齿音和环境声 |
autoGainControl | false | true | 自动增益会让音量忽大忽小 |
sampleRate | { ideal: 48000 } | { ideal: 48000 } | 不要硬写exact: 16000 |
channelCount | { ideal: 1 } | { ideal: 1 } | ideal不是强制，实际可能是双声道 |
exact是硬约束，设备不支持就报错；ideal是偏好，浏览器可以回退。更稳的做法是请求 48kHz，再用track.getSettings()读实际值，后台按实际采样率处理；需要 16k 单声道时，在前端用OfflineAudioContext或AudioWorklet重采样，不要假设浏览器一定按你写的来。
注意：
echoCancellation、noiseSuppression、autoGainControl在不同设备上未必生效，读getSettings()才能知道实际状态。
2.3 可执行步骤：从点击按钮到拿到 MediaStream
把开流封装成一个可重复调用的函数，每次先停旧轨，再申请新流；错误名映射成用户能看懂的提示。getUserMedia必须在用户手势或已授权后调用，不要在页面加载时自动弹权限框，否则用户还没理解要做什么就被拒绝，后面再申请会更麻烦。
const micState = { stream: null, deviceId: '' }; async function openMicrophone(deviceId) { if (!navigator.mediaDevices?.getUserMedia) { throw new Error('当前环境不支持麦克风采集'); } if (micState.stream) { micState.stream.getTracks().forEach((track) => track.stop()); micState.stream = null; } const audio = { echoCancellation: false, noiseSuppression: false, autoGainControl: false, channelCount: { ideal: 1 }, sampleRate: { ideal: 48000 } }; if (deviceId) audio.deviceId = { exact: deviceId }; try { const stream = await navigator.mediaDevices.getUserMedia({ audio, video: false }); micState.stream = stream; micState.deviceId = deviceId || ''; const track = stream.getAudioTracks()[0]; const settings = track.getSettings(); console.log('实际音频参数', settings); return stream; } catch (err) { // 常见错误名：NotAllowedError / NotFoundError / NotReadableError / OverconstrainedError throw new Error(`麦克风打开失败: ${err.name}`); } }这段函数的关键是“先停旧、再开新”，避免两个MediaStream同时占用麦克风。audio里只放真正需要的约束，deviceId为空时用默认设备；video: false明确只要音频。track.getSettings()返回的sampleRate、channelCount、deviceId才是实际值，后面上传时要带这些字段，不要拿请求参数当真实参数。
错误名要分开处理：NotAllowedError是用户拒绝或权限策略拦截；NotFoundError是没找到设备；NotReadableError常见于设备被其他程序占用；OverconstrainedError是约束太死；SecurityError多半是页面上下文不对。把错误名直接抛给业务层，比统一提示“麦克风打开失败”更容易排查。
3. 实时音频流怎么落地：H5 音频分段、编码格式与 Blob 组装
拿到MediaStream只是输入，真正要上传的是编码后的Blob。PC 端 H5 音频录音有两条路：MediaRecorder直接出压缩格式，或者 Web Audio 取 PCM 自己封 WAV。前者代码少、带宽低，适合语音留言；后者体积大，但时长、采样率、声道数完全可控，适合质检和语音识别。选型不要只看“能不能录”，要看后台能不能解、需不需要精确时长、要不要做波形。
3.1 选 MediaRecorder 还是 Web Audio PCM：延迟、格式与后台兼容性
MediaRecorder的优势是浏览器内置编码，语音场景 64kbps 左右的 Opus 已经够用；缺点是输出格式因环境而异，流式录制的 WebM 可能没有准确的时长元数据。Web Audio 路线需要AudioWorklet采集 PCM，再自己写 WAV 头，体积大约是压缩格式的十倍以上，但时长、采样率、声道数都可控，后台不需要转封装就能直接读。
| 方案 | 输出格式 | 体积 | 时长元数据 | 后台处理 | 适合 |
|---|---|---|---|---|---|
MediaRecorder | WebM/Opus、Ogg/Opus、M4A 等 | 小 | 流式录制可能缺失 | 需转封装/解码 | 语音留言、会议记录 |
| Web Audio PCM | WAV/PCM | 大 | 准确 | 直接读头 | 质检、ASR、波形 |
常见做法是：普通录音走MediaRecorder，后台要求 16k 单声道 WAV 时再走 PCM 兜底。不要为了“统一格式”强行在所有环境用 PCM，长录音的内存和上传体积会很难看；也不要为了省事只传 WebM，后台如果只收 WAV，联调时还是要返工。
3.2 timeslice 与 ondataavailable：分段大小、首包与尾包
MediaRecorder.start(timeslice)的timeslice决定多久派发一次dataavailable。不传时通常只在stop()时给一个完整 Blob；传 1000 表示大约每秒给一个分片。分片不是独立可播放文件，只是同一路码流的分段，必须按顺序拼成一个 Blob 再上传。把每个分片单独当文件上传，后台大概率只能解出第一段。
function pickMimeType() { const candidates = [ 'audio/webm;codecs=opus', 'audio/webm', 'audio/ogg;codecs=opus', 'audio/mp4' ]; return candidates.find( (type) => window.MediaRecorder && MediaRecorder.isTypeSupported(type) ) || ''; } function createAudioRecorder(stream, { bitrate = 64000, timeslice = 1000 } = {}) { const mimeType = pickMimeType(); const chunks = []; const recorder = new MediaRecorder(stream, { ...(mimeType ? { mimeType } : {}), audioBitsPerSecond: bitrate }); recorder.ondataavailable = (event) => { if (event.data && event.data.size > 0) { chunks.push(event.data); } }; const stopped = new Promise((resolve, reject) => { recorder.onstop = () => { const type = recorder.mimeType || mimeType || 'application/octet-stream'; const blob = new Blob(chunks, { type }); <p> <a href="https://download.csdn.net/download/weiqiang0124/10567495" style="color:#ec7500;font-size:14px;"> 本文还有配套的精品资源，点击获取 </a> <img alt="menu-r.4af5f7ec.gif" src="https://csdnimg.cn/release/wenkucmsfe/public/img/menu-r.4af5f7ec.gif" style="width:16px;margin-left:4px;vertical-align:text-bottom;cursor:text;"> </p>
