网页里点开采访录音没有声音，进度条却照常往前走，文件在电脑上双击又能正常播放——这类问题很容易被当成单一故障来处理。实际上AIFF音频在网页端无声，往往同时牵涉文件本身、浏览器解码能力和页面播放器三个层面，混在一起排查只会来回打转。
先确认文件是否完整
AIFF是苹果早期定义的一种音频封装格式，常见于录音和音频剪辑场景。核对时先看采样率、位深、声道数这几项参数，再看文件头信息是否完整。有些文件是剪辑软件导出中断产生的，头信息残缺，系统播放器能靠容错读出声音，浏览器却会直接放弃解析。最简单的交叉验证方法是：用系统自带播放器播一遍，再用浏览器直接打开文件地址播一遍。两边都有声音，问题基本不在文件；两边都无声，优先怀疑文件完整性。
再判断浏览器是否支持该格式
AIFF属于未压缩音频封装，体积大，浏览器原生支持的范围有限，不同内核的浏览器表现并不一致。有的浏览器能识别AIFF容器却解不出其中的PCM数据，有的干脆不认这个扩展名。确认文件本身完好之后，就要判断是否需要转码为网页通用格式。转码不是随便换个后缀，而是重新编码为浏览器普遍支持的音频格式，同时保留原始文件作为存档。判断标准很直接：目标用户的浏览器环境是否稳定支持AIFF，如果不支持，转码就是必要动作。
最后检查服务端与页面配置
文件上传后是否被系统自动转码，转码是否失败但页面没有任何提示，这些都要查。MIME类型是否配置正确同样关键，类型标注错误会让浏览器按错误方式处理文件。页面这边，audio标签里多个source的顺序、错误事件是否被监听并给出提示，也常被忽略。有的页面只写了一个source，加载失败后既不提示也不回退，用户看到的就是无声播放。
按顺序执行的排查清单
把以上环节串起来，可以形成一份按顺序执行的清单：先本地与浏览器双端试听，判断文件是否完好；再查文件参数与头信息；然后确认浏览器对该格式的支持情况，决定是否转码；最后核对服务端转码结果、MIME类型和页面播放器配置。it数运在网站维护中处理这类问题，通常也是先定位层级，再决定是转码还是改前端，避免一上来就改代码却找错方向。
判断标准可以归纳成两句话：能本地播放但网页无声，优先查解码支持与MIME配置；两端都无声，优先查文件完整性。把这两条放在前面，排查效率会高很多。
