后台能正常上传FLV视频，文件列表里也能看到，但打开页面就是一片黑，播放按钮点了没反应，有的浏览器干脆提示格式不支持。这种情况容易让人误以为是网站坏了，其实多数问题出在文件本身和播放链路上。排查时不必一上来就改代码，按封装、播放器、服务端三个层次逐项核对，往往能更快定位。
先确认文件到底是不是FLV容器。FLV是一种较老的封装格式，扩展名可以随意改，把MP4改名成FLV也会显示为FLV文件。核对方法是查看文件的真实类型，用系统自带的属性信息或命令行工具读取文件头，确认前几个字节是否为FLV标识。如果文件头对不上，说明扩展名是假的，需要让上传者提供原始文件。这一步能排除相当一部分误报。
接着核对视频编码。FLV容器里常见的视频编码有Sorenson H.263、VP6和H.264，音频常见MP3和AAC。浏览器原生video标签对FLV支持很有限，能播放的前提通常是内部封装了H.264加AAC，并且通过支持FLV的播放器或转码后以其他格式输出。如果编码是VP6或H.263，即使播放器加载成功也大概率黑屏。维护人员可以用媒体信息工具读取编码类型，把结果记录下来，作为后续判断依据。
第三层看播放器与转码链路。如果网站使用的是通用播放器组件，要先确认该组件是否声明支持FLV，以及是否依赖额外的脚本或插件。有些方案是上传后由服务端转成HLS或MP4再播放，此时页面里看到的地址可能不是原始FLV文件。核对时打开浏览器开发者工具的网络面板，看实际请求的是哪个地址、返回状态码是多少、响应内容类型是什么。如果请求的是转码后的地址却返回错误，问题就在转码任务，而不在播放器。转码未完成、任务失败、队列积压都会表现为无法播放。
第四层核对服务端响应与文件完整性。上传中断会留下大小异常的文件，播放器读取到一半就停住。对比文件大小与上传记录是否一致，能快速发现截断。另外检查服务器返回的Content-Type，FLV应为video/x-flv，如果被配置成application/octet-stream或text/plain，部分浏览器会拒绝播放。还要留意是否有防盗链、权限校验或跨域限制拦截了媒体请求，这类问题在控制台里通常能看到明确的报错信息。
处理完之后建议留一份维护记录，写清文件名、真实容器、视频编码、音频编码、文件大小、实际请求地址、响应状态和最终处理方式。回归验证时不要只看一个浏览器，至少在两个主流浏览器和移动端各测一次，并确认拖动进度条、暂停续播正常。具体处理方式应以实际服务器环境、播放器版本和浏览器表现为准，涉及转码参数调整时，建议先在小范围文件上验证再全量应用。把每次核对的结果沉淀下来，同类问题下次就能少走弯路。
