构建可用网页录音机需统一输出格式：用web audio api截取pcm并封装wav，前置获取麦克风权限，动态检测mimetype，对.m4a用decodeaudiodata解码为pcm。
要构建一个真正可用的网页录音机，光靠 MediaRecorder 默认输出是不够的——它在不同浏览器里生成的格式不统一（Chrome 输出 .webm，Safari 基本只认 .m4a，而很多后端或语音识别服务只接受标准 .wav）。所以关键不在“能不能录”，而在“录出来的能不能直接用”。核心思路是：用 getUserMedia 拿到原始音频流，再通过 Web Audio API 拦截 PCM 数据，最后在前端拼装成规范的 WAV 文件头 + PCM 数据体。整个过程不依赖服务端转码，兼容主流浏览器，也规避了格式协商的麻烦。
麦克风权限与音频流获取要前置处理
别等用户点“开始录音”才去申请麦克风权限。移动端尤其容易失败：用户长按按钮时弹出授权框，等他点完“允许”，手势已松开，录音逻辑就断了。应该在页面加载完成、或用户切换到语音输入模式时，就静默调用一次 navigator.mediaDevices.getUserMedia({ audio: true })。成功后把 MediaStream 缓存起来，后续录音直接复用，避免重复触发权限弹窗。
用 MediaRecorder 录制时指定 mimeType 稳定输出
虽然跨浏览器一致性差，但可以尽量收窄范围：
- Chrome 和 Edge 支持
mimeType: 'audio/webm;codecs=opus'，体积小、质量好，适合上传前压缩 - Firefox 支持
'audio/wav'，但 Safari 完全不认；若后端必须 WAV，就别依赖它，改走 Web Audio 自组方案 - 不要写死
mimeType，先用MediaRecorder.isTypeSupported()检测当前浏览器支持哪些，再动态选择最稳妥的一种
Web Audio 方案：自己组装 WAV 文件
这是解决格式统一问题的硬核但可靠路径：
- 创建
AudioContext，用mediaStreamDestination节点把麦克风流接入上下文 - 用
ScriptProcessorNode（已废弃）或更现代的AudioWorklet定期采集 PCM 数据（推荐后者，避免主线程阻塞） - 每段 PCM 数据是
Float32Array，需转为Int16Array（WAV 标准采样位深），再按 little-endian 字节序打包 - 手动构造 WAV 文件头（44 字节），填入采样率、声道数、位深度、数据块大小等字段，拼接 PCM 数据体，最后封装为
Blob
对 .m4a 文件做前端解码与重编码
如果用户上传的是 iOS 录制的 .m4a，又需要转成 PCM 或 WAV 供分析/识别，可走以下轻量路径：
- 用
fetch读取文件为ArrayBuffer，传给AudioContext.decodeAudioData()解码为AudioBuffer - 从
AudioBuffer中提取各声道的Float32Array数据（即 PCM） - 若需导出为 WAV，复用上一步的封装逻辑；若只需送语音识别，多数 SDK 接受
Float32Array或Uint8Array格式 - 注意：iOS Safari 对
decodeAudioData有严格限制（如仅支持 AAC-LC），大文件建议分段解码防卡顿
大量免费API接口：立即使用
涵盖生活服务API、金融科技API、企业工商API、等相关的API接口服务。免费API接口可安全、合规地连接上下游，为数据API应用能力赋能！
