Blob是HTML5音频录制与上传的核心载体，直接封装原始二进制片段，用于本地预览和上传；需通过MediaRecorder分段采集、复制暂存、校验类型与大小，再以FormData直接提交，服务端须按序用FFmpeg等工具合并而非简单字节拼接。
HTML5 音频录制与上传中，Blob 不是中间格式，而是核心载体——它直接封装原始音频二进制片段，既用于本地预览播放，也作为上传的最小数据单元。关键不在“转格式”，而在如何稳定采集、安全暂存、有序传输。
录音阶段：用 MediaRecorder 捕获并分段存为 Blob
调用 navigator.mediaDevices.getUserMedia({ audio: true }) 获取麦克风流后，传给 MediaRecorder 实例。每次触发 dataavailable 事件，event.data 就是一个原生 Blob，包含当前时段的编码音频（如 audio/webm 或 audio/mp4）。不要直接上传 event.data，而应立即复制：
- 用
new Blob([event.data], { type: event.data.type })创建独立引用，防止被垃圾回收或复用 - 把 Blob 和序号、时间戳一起存入数组，例如：
segments.push({ blob, index: i, timestamp: Date.now() }) - 若需固定时长分段（如每 3 秒一段），可设
timeslice: 3000；若需按大小控制（如每 512KB 一段），则禁用 timeslice，改用recorder.requestData()主动截取
上传前：确认 Blob 类型与完整性
Blob 的 type 属性决定服务端解码方式，必须准确。常见类型有 audio/webm（Chrome 默认）、audio/mpeg（MP3）、audio/wav（未压缩）。上传前建议校验：
- 检查
blob.type是否非空，避免上传空类型导致服务端解析失败 - 记录
blob.size，上传后比对服务端返回的接收字节数，识别截断风险 - 若需兼容老系统，可在 FormData 中附加字段说明格式，例如：
formData.append('format', 'webm')
上传过程：以 Blob 为单位构造请求体
不推荐将 Blob 转成 base64 或 ArrayBuffer 再上传——会增大体积、增加编码开销。直接使用 FormData 提交最高效：
立即学习“前端免费学习笔记（深入）”；
-
formData.append('audio', blob, 'recording.webm')—— 第三个参数指定文件名，影响服务端Content-Disposition - 同时附带上下文信息：
formData.append('index', i)、formData.append('session_id', sessionId) - 若用 fetch，可直接传
formData；若用 XMLHttpRequest，确保设置xhr.send(formData)，无需手动设置Content-Type（浏览器自动加 boundary）
服务端还原：拼接 Blob ≠ 简单字节合并
多个音频 Blob 按序上传后，服务端不能简单用 Buffer.concat() 合并——尤其 MP4/WebM 等容器格式含头部元数据和帧索引。稳妥做法是：
- 先按
index排序所有分段，写入临时文件或内存缓冲 - 用 FFmpeg 或类似工具合并：
ffmpeg -f webm -i "concat:seg0.webm|seg1.webm|..." -c copy output.webm - 若客户端统一录为 WAV（无容器头），服务端才可安全二进制拼接，但文件体积大、不适用于长录音
- 最终生成播放 URL 前，建议校验总时长、MD5 或尝试用 ffprobe 解析首尾帧，确认完整性
