网页音频“能播放但时长为零”的排查方法
有用户反馈，上传的MP3在网页里点开能正常出声，进度条却一直停在起点，总时长显示00:00。不少人的第一反应是文件坏了，于是重新上传、重新转码，折腾一圈问题依旧。“能播放”和“能读出时长”其实是两条不同的链路，前者依赖解码输出，后者依赖元数据解析。把这两件事分开看，排查方向会清楚很多。
第一层，先核对文件本身。把同一个MP3下载到本地，用系统自带播放器或常用音频软件打开，看是否正常显示总时长。如果本地也显示异常，问题多半在文件侧。这时要区分编码方式：固定码率文件结构规整，时长信息容易读取；可变码率文件如果没有写入完整的时长头信息，部分解析器就只能边播边算，初始阶段读不到总长。遇到这种情况，可以用转码工具重新导出一份固定码率的副本做对照测试，若副本正常，说明原文件的元数据确实不完整，而不是网页端出了故障。
第二层，核对浏览器解码能力。不同浏览器对音频容器和编码的支持并不完全一致，同一文件在甲浏览器正常、乙浏览器异常是常见现象。维护人员可以做一个最小复现页面，只放一个音频元素和一行读取时长的脚本，不引入任何框架和插件，分别在目标浏览器里打开。如果最小页面能读出时长，说明问题出在原页面的加载逻辑；如果最小页面同样为零，再换一个编码格式的文件交叉验证，就能判断是文件与浏览器的组合问题，还是页面本身的问题。
第三层，核对网页端的读取逻辑。时长不是随时都能拿到的，它要等元数据加载完成才可用。有些页面在元素刚创建、资源还没开始加载时就读取时长，拿到的自然是零，而且之后不再更新。合理的做法是监听元数据加载完成事件，在回调里读取时长并写入界面，同时处理加载失败的情况。还要注意事件监听的注册顺序，先绑定再设置资源地址，避免事件已经触发而监听还没挂上。若页面存在多次初始化或重复渲染，也要确认读取动作没有被覆盖。
第四层，核对服务端响应。文件传输不完整，浏览器拿到的只是前半段数据，元数据可能恰好落在缺失的部分。检查响应头中的内容长度是否与实际文件大小一致，确认服务端是否支持分段请求，以及在分段请求下返回的状态码和范围是否正确。传输被中断、压缩配置改动、缓存了旧版本文件，都可能造成这类现象。用浏览器开发者工具查看网络请求的响应状态和实际接收字节数，是最直接的确认方式。
给维护人员一份可执行的清单：先本地验证时长是否正常，再记录文件编码方式与大小，然后用最小页面在目标浏览器复现，接着检查页面读取时长的时机与事件绑定，最后核对服务端响应头与传输完整性。每一步都把结果记下来，包括浏览器名称、版本、操作系统和测试时间，便于后续对比。涉及具体浏览器版本的表现时，应以实际测试结果为准，不同版本之间可能存在差异。按这个顺序走一遍，多数“时长为零”的问题都能定位到具体环节，而不是停留在反复替换文件的循环里。
