后台收到一段WAV音频，进度条走完了，播放按钮也切换成了暂停状态，耳机里却一点声音都没有。遇到这类反馈，最省事的做法是先把锅甩给“浏览器不支持WAV”，但WAV只是一个容器名字，里面装的内容差别可以很大。先别急着转格式，按文件本身、位深参数、文件头、服务端处理、播放器配置这五层逐项核对，多数问题在前三层就能定位。
第一层：先看封装，WAV不等于PCM
WAV是容器，不是编码格式。常见的是PCM裸数据，但也有一些WAV文件实际封装的是压缩编码。把文件拖进音频信息工具，先确认编码类型是不是PCM，再看采样率、声道数、位深这三个数值。采样率低于8kHz或高于192kHz、声道数异常、位深显示为0，都属于可疑信号。这一步只做记录，先不下结论。
第二层：位深与采样率的兼容边界
16位PCM在主流浏览器里兼容性最好，24位多数现代浏览器可以处理，32位浮点则要看具体实现，部分环境会解码失败但不报错，表现就是静音。采样率方面，44.1kHz和48kHz最稳，96kHz以上有些浏览器会尝试重采样，重采样环节出错时同样没有声音。可以拿同一段内容导出一份16位44.1kHz的版本做对照，如果对照文件能响，问题基本锁定在参数上。
第三层：文件头完整性容易被忽略
用工具查看RIFF头里声明的data块长度，和文件实际大小做减法比对。上传过程中断、存储写入不完整，都会让声明长度大于实际数据，浏览器读到一半拿不到样本，就安静地停下。这类文件往往还能显示时长，更具迷惑性。重新上传一次并核对服务端文件大小，是最快的验证方式。
第四层：浏览器与服务端处理
检查响应头里的Content-Type是不是audio/wav或audio/x-wav，被识别成application/octet-stream时，部分播放器会直接放弃。如果站点有转码流程，确认WAV有没有被规则跳过。走CDN的话，还要看边缘节点返回的类型是否被改写。
第五层：播放器配置的细节
audio标签里多个source的顺序会影响选择，写了codecs参数但和实际编码不符也会导致静默。再确认音量、静音状态和页面其他音频是否抢占。逐层记录文件编码、位深、采样率、文件大小、响应类型和播放器配置，形成一份可复用的排查记录。
具体浏览器版本和转码服务的表现存在差异，应以实际环境测试结果为准。it数运在处理此类维护问题时，也习惯先把这几层信息收齐再动手，避免在错误的方向上反复改代码。技术有章法，服务有回应，排查音频问题同样适用这个思路。
