企业站视频上传后显示成功，前台却黑屏无响应，这类情况在运维中并不少见。文件大小正常、后台无报错，很多人第一反应是文件损坏，于是反复重传、换浏览器、清缓存，一圈下来问题依旧。真正的原因往往不在文件本身，而在于封装格式与浏览器支持之间的错位。FLV是早期流媒体常用的容器格式，主流浏览器如今已不再原生支持，必须经过转码才能进入网页播放链路。排查时按文件、服务端、前端三层依次核对，比盲目重传更省时间。
第一层：先确认文件本身
先看扩展名与实际封装是否一致。有些文件后缀写着flv，内部却是别的容器格式，仅凭文件名判断容易误判。再核对音视频编码组合，FLV中常见的视频编码与音频编码搭配，如果落在浏览器普遍不支持的范围，即便容器能被识别，播放依然会失败。
这一步的判断标准很直接：文件能在本地播放器打开，说明数据大体完整；但本地能播不等于网页能播，两者支持的格式范围并不相同。把这两个结论分开看，能避免很多无效操作。
第二层：核对服务端处理链路
不少网站后台设有转码任务，上传后应自动转为网页友好的格式。需要确认任务是否真的触发、队列里有没有积压、转码日志是否记录了失败原因。还要看输出参数，分辨率、码率、音频采样是否落在网页播放的合理区间。
有一种情况容易被忽略：转码显示成功，但输出文件异常偏小，往往是中途中断留下的半成品，这类文件在前台同样表现为黑屏。核对时不能只看任务状态，还要比对输出文件的大小与时长是否合理。
第三层：检查前端播放器
查看播放器声明的支持格式清单，确认FLV是否在列。更隐蔽的情况是错误回调被静默吞掉，播放失败时页面没有任何提示，用户只看到黑屏，维护人员也拿不到线索。建议在播放器初始化时保留错误监听，把失败原因输出到控制台或日志，排查时才有依据。
一份可执行的兼容性检查清单
为减少反复排查，可以整理一份上传兼容性检查清单，让每一项都能被验证：
明确允许上传的格式范围，写清哪些格式必须触发转码；
规定转码失败时的提示文案，避免用户面对无声黑屏；
保留人工兜底入口，让用户知道可以联系谁；
记录每次转码的输入输出参数，便于回溯比对。
清单不必复杂，关键是落到可查、可对照的程度。
长期做法：上传即校验、异步转码、保留原始文件
更稳妥的流程是三层配合：上传时先读取封装与编码信息，不符合要求的直接提示；转码放到后台异步执行，不阻塞用户操作；原始文件保留一段时间，便于回溯。这样下次再遇到类似问题，判断顺序清晰，处理成本也会明显下降。
it数运在网站维护中一直强调把问题分层说清楚，先定位在哪一层，再谈怎么修，避免把格式兼容问题误当成文件损坏反复折腾。技术有章法，服务有回应，很多看似棘手的播放故障，拆开来看不过是某一层没有核对到位。
