html5音频录制中无法直接设置采样率，实际由硬件与浏览器决定（通常44.1/48khz）；需通过audiocontext重采样统一输入，用audioworklet替代废弃的scriptprocessornode做轻量预处理，mediarecorder应选用audio/webm;codecs=opus等高效编码格式，并分层处理原始数据。
HTML5 音频采样与录制流程中，真正可控的不是“设置采样率”，而是如何在采集、处理、编码各环节减少冗余、匹配场景、规避性能陷阱。浏览器不提供直接配置采样率的接口，所有所谓“控制”都发生在链路中的特定节点。
音频流源头：getUserMedia 只能请求，不能指定
调用 navigator.mediaDevices.getUserMedia({ audio: true }) 时传入的 sampleRate 选项（如 { audio: { sampleRate: 16000 } }）在所有主流浏览器中均被忽略——它不是标准支持参数。实际采样率由设备硬件、操作系统音频栈和浏览器实现共同决定，通常为 44.1kHz 或 48kHz。
- 不要依赖约束对象里的
sampleRate字段做质量控制 - 可通过
AudioContext.sampleRate读取当前上下文实际采样率（只读），作为后续重采样的参考基准 - 若需统一输入源为 16kHz（例如语音识别或低带宽上传），必须在获取流后，用
AudioContext主动重采样，而非靠 getUserMedia “协商”
实时处理环节：避开 ScriptProcessorNode，用 AudioWorklet 做轻量预处理
旧式 ScriptProcessorNode 已废弃，主线程阻塞、调度不准、延迟高，不适合任何生产环境。现代方案是 AudioWorklet —— 它在独立线程运行，可稳定处理每帧音频数据，且不干扰 UI。
- 适合做短时能量检测、静音裁剪、增益归一化等轻量级预处理
- 避免在 onaudioprocess 中做 Blob 构造、Base64 编码、IndexedDB 写入等耗时操作；这些应移交 Web Worker
- 若仅需降噪或均衡，优先使用内置节点（
GainNode、BiquadFilterNode），比自定义 Worklet 更高效
录制输出环节：用 MediaRecorder + 合理 mimeType 替代“硬控采样率”
MediaRecorder 不暴露采样率设置，但它的 mimeType 直接影响最终文件体积与带宽适应性。与其纠结数字，不如选对编码：
- 首选
audio/webm;codecs=opus：Opus 天然适配 8–24kHz 语音带宽，动态码率（最低可设 6kbps），体积小、延迟低、兼容好 - 避免
audio/wav：PCM 无压缩，48kHz 立体声 ≈ 1.5MB/分钟，极易触发移动端内存警告或上传超时 - Safari 用户注意：
audio/mp4（AAC）是唯一选择，但默认采样率常为 44.1kHz；如需压缩，可在前端用FFmpeg.wasm转码（如转为 16kHz AAC-LC @24kbps）
后处理与存储：分阶段解耦，按需转换
原始录制数据（Blob）不宜直接存档或上传。建议按用途分层处理：
- 实时监听：用
MediaStream直连AudioContext.destination，加GainNode控制播放音量，避免系统音量突变 - 本地缓存：存为压缩格式（如 Opus WebM），而非原始 PCM；IndexedDB 存储前建议加简单元数据（时长、码率、设备型号）
- 服务端交付：上传后由后端统一转码（如 FFmpeg 转 16kHz mono MP3），既节省前端算力，又保证格式一致性
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
