网页端FLAC播放异常：先分清兼容、转码与文件三层
用户上传一段FLAC无损音频，在网页端点击播放没有反应，或者进度条刚走一点就停住。遇到这类反馈，不必急着判定文件损坏。FLAC在本地播放器里能正常播放，说明音频数据本身大概率是完整的，问题更可能藏在浏览器兼容、服务端转码链路或播放器配置这三个环节里。排查的第一步不是改代码，而是把这三层拆开逐一验证。
先核对浏览器与播放器的支持范围。这里要分清容器格式和编码格式：FLAC既是一种容器，也是一种编码方式，各浏览器对它的支持并不统一。部分浏览器在桌面端可以原生播放FLAC，移动端或内嵌浏览器则可能不支持；同一浏览器的不同版本之间也可能存在差异。核对方法是准备一个已知可播放的短FLAC样本，在用户使用的同类浏览器中测试，同时查看播放器组件是否声明支持该格式。如果样本也无法播放，问题就落在兼容层；如果样本正常，再回头检查用户文件本身。
第二层核对服务端转码与响应头。不少网站并不直接输出FLAC，而是由服务端转成其他格式再交给播放器。这时要确认转码任务是否成功完成、输出文件是否存在、响应头中的Content-Type是否与实际输出格式一致。另一个容易被忽略的点是Range请求：音频播放依赖分段加载，如果服务端不支持或错误处理Range请求，播放器可能拿不到完整数据而中断。核对时可直接请求音频地址，观察状态码和响应头字段是否正常。
第三层核对文件本身。FLAC支持多种采样率、位深和声道数，部分播放器对高采样率或多声道文件处理能力有限。建议逐项记录：采样率、位深、声道数、文件大小、时长，再与播放器文档中标注的支持范围对照。超出范围不代表文件有问题，但需要转码或更换播放方案。记录表的价值在于，同样的反馈再次出现时可以直接比对，不必从头猜测。
整理排查顺序时，可以先向用户收集浏览器名称与版本、操作系统、播放失败的具体表现、文件来源和基本信息，再在可控环境中复现。复现之后再定位，定位之后再修改，修改之后留下记录。不能凭猜测下结论，比如把播放失败直接归因于文件损坏，或未经测试就断定是浏览器问题。
维护流程上，先复现再定位、先记录再修改，比反复试错更省时间。it数运在网站维护中通常会把用户反馈、复现环境、核对项和最终处理方式一并留存，便于后续同类问题快速比对。技术问题说明白，交付过程做清楚，排查链路才不会每次都从零开始。
