iPhone拍摄的视频上传到网站后，部分安卓手机浏览器打开时只有声音没有画面，进度条正常推进，画面却始终卡住。遇到这种情况，多数人的第一反应是文件损坏，于是重新上传，结果依旧。实际上，MOV文件本身往往是完整的，问题出在封装标识与播放链路的匹配上。下面按四个层次梳理核对顺序，帮助维护人员快速定位。
第一层：核对容器与编码标识
MOV只是一个容器外壳，真正决定能否出画面的是内部视频轨的编码格式。iPhone默认拍摄的MOV，视频轨常见为HEVC，也就是H.265，部分机型或设置下为H.264。安卓端浏览器内核对HEVC的支持并不统一，同一款浏览器在不同机型、不同系统版本上表现也可能不同。核对时可以先查看文件的编码信息，确认视频轨是HEVC还是H.264，再看音频轨是否为AAC。如果视频轨是HEVC，而目标安卓环境不支持，浏览器就会退化为只解析音频轨，出现有声无画。
另一个容易被忽略的点是moov的位置。MOV的索引信息moov如果位于文件尾部，浏览器需要先拿到整个文件才能开始解析，边下边播的场景下容易出现只加载音频的情况。核对时可以确认moov是否前置，必要时在上传环节做一次快速重组。
第二层：核对服务端转码策略
不能把播放完全交给浏览器原生能力。服务端在上传完成后，应当根据目标终端做一次转码或至少做一次兼容性封装转换，把HEVC视频轨转为H.264，把moov前置，输出通用的MP4。核对时看三件事：转码任务是否真正执行成功，转码后的文件编码是否符合预期，转码产物是否替换了原始播放地址。有些站点转码任务配置了但未触发，或者转码失败后静默保留了原文件，前端拿到的仍是HEVC版本，问题自然复现。
第三层：核对前端播放器与回退源
播放器层面要有明确的回退设计。检查清单可以这样列：是否同时提供转码后的MP4源与原始MOV源；播放器是否按能力检测顺序选择源；是否在检测到视频轨不可解码时给出提示而不是静默播放音频；是否针对安卓端单独验证过播放效果。多源准备的意义在于，当某个源在特定终端不可用时，播放器能切换到可用源，而不是让用户面对一块黑屏。
第四层：核对上传环节的元信息记录
排查要能复盘，就要在上传时记录足够的信息。建议记录原始文件名、容器类型、视频轨编码、音频轨编码、文件大小、上传时间、转码状态与转码后地址。有了这些字段，下次再遇到有声无画，可以直接比对是哪个环节的标识不匹配，而不必反复试错。日常维护中，这份记录也是判断问题属于个别文件还是批量现象的依据。
整体排查顺序可以归纳为：先看视频轨编码与moov位置，再看服务端转码是否生效，然后看前端是否具备回退源，最后用元信息记录完成闭环。把这四层固定成检查表，多数有声无画的问题能在前两层定位。
在网站维护的实际交付中，it数运通常会把上传文件的编码信息、转码结果和播放验证记录一并整理交付，遇到终端兼容问题时按层核对、及时回应，让排查过程有据可查。技术问题说明白，交付过程做清楚，后续维护才不会反复踩同一个坑。
