同一段MOV视频在电脑上能正常播放，上传到网站后用安卓手机打开却变成黑屏，有时只剩声音，有时连声音也没有。遇到这类反馈，先别急着认定文件损坏。黑屏一般分两种情况：一种是解码没有通过，设备根本没解出画面；另一种是解码已经完成，但渲染环节没有触发，画面层拿不到可显示的数据。两种表现看起来相近，排查路径却不一样。先确认文件在本地能否正常播放，再按下面的顺序逐层核对。
第一层：容器与轨道结构是否被安卓识别
MOV本身是一种容器格式，里面可以封装不同编码的视频轨和音频轨。安卓设备能支持哪些解码器，取决于系统版本和厂商实现，并不是MOV里常见的编码都能顺利解码。核对时先看视频轨的编码类型，再看音频轨是否独立存在。如果视频轨用了安卓端支持面较窄的编码，播放器可能只解出音频，画面保持黑屏。这时文件并没有损坏，而是解码链路在第一步就没有走通。建议用通用的媒体信息查看工具确认轨道数量、编码名称和时长，避免把容器问题和编码问题混在一起判断。
第二层：像素格式与色彩标记是否被跳过
即使编码本身可以解码，像素格式和色彩标记也可能让画面无法输出。部分像素格式在移动端解码链路中会被直接跳过，播放器拿不到可渲染的帧数据，表现就是黑屏。色彩标记异常时，有的设备会放弃渲染，而不是显示偏色画面。核对这一层，需要查看视频轨的像素格式描述和色彩范围标记，确认是否属于移动端常见支持范围。若不确定，可先用同一段素材转成通用像素格式做对照测试，能显示画面就说明问题出在这一层。
第三层：浏览器与服务端转码策略是否缺位
网站维护中常见的情况是，上传环节只做了文件接收，没有做媒体兼容处理。用户上传的MOV被原样存储，前端播放器直接引用，兼容性完全交给用户设备。更稳妥的做法是在上传后统一转封装为通用格式，再提供给播放端。检查清单可以包括：上传完成是否触发转码任务、转码失败是否有记录、转码后的文件是否替换了原始引用、移动端请求是否优先返回兼容版本。这几项只要有一项缺失，黑屏就可能反复出现。
第四层：播放器回退逻辑是否到位
当解码确实无法完成时，播放器不应只留一块黑屏。合理的降级做法是优先显示明确提示，说明当前设备可能不支持该视频格式，同时提供下载入口或兼容版本链接。回退逻辑还要避免自动重试造成的卡顿，提示信息应指向可操作的下一步，而不是让用户反复刷新。对于批量上传的场景，可以在列表页标注媒体兼容状态，减少用户逐个点开的成本。
把核对顺序固定下来
可执行的顺序是：先确认本地播放正常，排除文件损坏；再查容器与视频轨编码，判断安卓解码器是否支持；接着核对像素格式与色彩标记，看渲染数据是否被跳过；然后检查上传后的转封装策略是否生效；最后确认播放器回退提示与下载入口是否可用。按这个顺序走，多数黑屏问题都能定位到具体环节。
it数运在网站维护中的做法，是把媒体兼容检查前置到上传环节，在文件进入存储之前就识别轨道结构和编码类型，对移动端支持面较窄的格式主动转封装，并保留原始文件备查。这样播放端拿到的是已经处理过的版本，黑屏反馈会明显减少，排查时也有据可依。技术有章法，服务有回应，媒体兼容这件事同样需要把检查做在问题发生之前。
