HTML前端经Flask后端传录音至Google Cloud Speech遇故障求助

• getUserMedia的采样率设置对MediaRecorder完全不生效
  写在getUserMedia({audio: {sampleRate: 16000}})里的采样率约束，只有当音频流经过AudioContext链路做实时重采样时才会生效；如果直接把拿到的原始硬件流传给MediaRecorder，浏览器会忽略这个参数，按照麦克风原生的输出采样率（多数消费级设备为48000Hz）录制音频。此时你给API配置的16000Hz采样率和实际音频的采样率差三倍，根本无法正常解码帧数据，自然返回空结果。可以直接把后端收到的FLAC字节存成本地文件，用媒体解析工具读取真实采样率做校验，不要盲信前端传的采样率参数。
• MediaRecorder的FLAC格式支持存在静默兼容问题
  并非所有浏览器都原生支持录制audio/flac格式，部分浏览器在收到不支持的mimeType配置时，不会抛出任何报错，而是静默生成webm/opus编码的音频Blob，仅在Blob的type属性上保留你预设的audio/flac标识。此时传给API的字节流根本不是有效FLAC文件，自然无法被解析。建议在录制启动时直接打印mediaRecorder.mimeType，确认浏览器实际生效的录制格式，不要仅以初始化时传入的参数判断格式正确性。
• Base64编解码流程损坏了音频字节流
  前端用FileReader.readAsDataURL生成的Base64字符串会固定携带data:audio/flac;base64,的文本前缀，如果后端直接对完整字符串做Base64解码，生成的字节流开头会混入这段文本垃圾，直接破坏FLAC文件的头部结构，导致解析失败。除此之外，Base64字符串在表单传输过程中被截断、混入空格或换行符、使用了URL-safe Base64但未转换回标准Base64格式，都会导致最终解码出的音频文件无法正常打开。
• 麦克风返回了全静音的无效流
  当前主流浏览器要求getUserMedia只能在HTTPS协议或localhost环境下调用，如果你的Flask应用是通过HTTP局域网IP访问的，浏览器会静默授予麦克风权限但返回全静音的音频流，录制出来的音频全程没有有效声纹。Google Speech API识别到纯静音内容时，不会返回任何识别结果，只会输出空的列表。
• FLAC文件结构不符合API解析规则
  部分浏览器实现的MediaRecorder在生成FLAC文件时，会将包含采样率、位深、声道信息的元数据块放在文件尾部，而Google Speech API默认从FLAC文件头部读取这些元数据。如果元数据不在预期位置，API会完全按照你传入的RecognitionConfig参数强行解码音频，一旦参数和实际音频的编码规则不匹配，就会出现解码失败、结果为空的问题。
• 提交的音频是不完整的无效片段
  如果录制的音频总时长不足0.1秒，或因为MediaRecorder的onstop事件触发时序错误，提交的Blob是录制过程中还未写完的临时片段，Google Speech API不会返回有效识别结果，只会输出空列表。

内容的提问来源于stack exchange，提问作者Jacob Crisan