网页上打开FLV视频，声音正常、进度条也在走，画面却一片空白或一直卡在加载状态。遇到这类反馈，很多人会直接归到“视频不能播”，但真正排查时，第一步应当把两种现象分开：一种是文件加载失败、播放器直接报错；另一种是能播、有声音、进度条正常，唯独没有画面。后者通常不是文件丢失，而更可能出在封装格式、视频编码和播放器渲染这几个环节。方向定错，后面的排查就容易做无用功。
先核对文件本身。让用户用本地播放器打开同一个FLV文件，确认画面是否正常。如果本地也无声无画，说明文件在生成或传输环节已经损坏；如果本地正常，问题就集中在网页端处理链路上。接着查看文件的视频轨信息，FLV封装中常见的视频编码有H.263、VP6、H.264等，其中前两种在浏览器端的支持度较低，尤其在不做转码、直接原文件播放的情况下，很容易出现只解析出音频轨的情况。核对时重点看两件事：文件里是否真的存在视频轨，以及视频编码是不是网页端普遍支持的类型。
再核对服务端的转码与封装。有些上传流程会先做一次格式处理，如果转码参数配置不完整，比如只指定了音频输出、视频轨被丢弃，或者输出容器与编码不匹配，就会出现“文件看起来是视频，实际只剩一条音轨”的结果。核对方法是取转码后的文件，用同样的方式检查轨道信息，对比原始文件与处理后文件的差异。如果原始文件有视频轨、处理后没有，问题就锁定在这一层，需要检查转码任务的输出参数是否包含视频编码、分辨率、帧率等完整配置。
最后核对播放器与浏览器环境。播放器对FLV封装的支持程度、是否启用了硬件解码、桌面端与移动端的解码能力差异，都会影响画面能否渲染。可以做一个简单对照：同一文件换一个浏览器、换一台设备打开，观察现象是否一致。如果只在某一端无画面，优先怀疑该端的解码支持或播放器配置；如果所有端都无画面，则回到前两层继续核对。
实际排查可以按这个顺序走：先本地播放验证文件完整性，再检查视频轨与编码类型，然后对比转码前后文件差异，最后做跨浏览器跨设备对照。修复顺序也对应这个逻辑，文件本身有问题就重新上传或重新生成，编码不支持就转码为标准格式，转码参数缺失就补齐配置，播放器不兼容就调整播放方案。长期来看，更稳妥的做法是在上传入口统一做一次转码，把用户提交的各种格式转换为网页端支持良好的标准格式，从源头减少这类兼容问题。
it数运在网站维护中处理上传文件兼容问题时，通常也是按这个思路推进：先判断问题落在哪一层，再决定改配置还是改流程，而不是一上来就换播放器或重写页面。技术有章法，服务有回应，把层级分清，排查才不会在原地打转。
