运营同事把一段产品演示视频上传到网站后台，文件是WEBM格式。在Chrome里点开播放正常，换到Safari却只看到播放器灰屏或者一句无法播放的提示。遇到这种情况，先不要急着判定是浏览器不支持，也不要直接让上传者换文件重传，更稳妥的做法是把问题拆成两层：一层是浏览器对格式的支持范围，另一层是文件本身的实际编码。两者混在一起判断，很容易改错方向。
第一层核对封装与编码组合。WEBM是一种容器格式，里面装什么编码才是关键。常见的视频编码有VP8、VP9、AV1，音频编码多见Opus和Vorbis。不同浏览器对这些组合的支持并不一致，同一段WEBM在某个浏览器能放，在另一个浏览器打不开，往往不是容器的问题，而是容器里的编码组合超出了对方的支持范围。所以看到WEBM打不开，第一步不是换扩展名，而是确认里面装的是哪种视频编码和音频编码。
第二层核对文件的实际编码信息。扩展名只能说明容器类型，不能说明内部编码。可以用公开的媒体信息查看工具读取文件的编码参数，重点看视频编码、音频编码、分辨率、帧率和音频采样率。有些文件是从其他格式转过来的，扩展名改成了WEBM，内部编码却没变，这类文件在部分浏览器上就会出问题。核对时把参数记录下来，再对照浏览器的公开支持说明，判断是编码不被支持，还是参数超出常见范围。
第三层核对网页播放器与回退方案。如果页面只写了一个视频源，浏览器不支持该编码时就只能报错。合理的做法是在视频标签内提供多个来源，让浏览器按顺序选择自己能播放的格式，例如同时准备WEBM和MP4两个版本，并在来源标签中标注类型。常见配置错误包括来源顺序不合理、类型标注与实际编码不符、只保留一个来源却没有备选。回退方案的意义在于覆盖不同浏览器的支持差异，而不是指望一个文件通吃所有环境。
第四层核对转码与上传流程。与其每次上传后逐个浏览器测试，不如在上传前统一处理：把视频转成兼容范围更广的编码组合，保留原始文件备查，转码后核对时长、画面比例和音画同步是否正常，再上传并分别在主流浏览器中实际播放验证。维护记录里写清转码参数和验证结果，后续遇到同类问题可以直接对照，减少重复排查。
把上面的内容收拢成可执行的顺序：先确认现象出现在哪个浏览器、哪个页面；再读取文件的实际编码参数；然后检查页面是否提供了多格式回退；最后回到上传流程，统一转码并保留原始文件。兼容性结论应以浏览器官方文档和实际播放测试为准，不同版本的支持情况可能存在差异。it数运在网站维护中处理这类问题时，也是按这个顺序逐层核对，把判断依据留清楚，避免靠猜测反复改文件。
