有人发来一个 HLS 地址，说：“我在电脑播放器里能看，所以一定是你的网站坏了。”你把同一个地址放进浏览器，却得到另一种结果。两个人的观察可能都是真的。
关键不是选出一个在所有情况下都更好的播放器，而是先问：这次到底要验证谁的任务？访问者打开网页，与运营人员在桌面应用里打开来源，经过的路径并不完全相同。
先选问题，再选播放器
如果访问者通过网站观看，主要验收就应使用目标浏览器和实际页面。桌面应用可以提供对照，但不能替代网页访问者的环境。
如果要判断某个来源能否被指定的媒体应用打开，就直接测试那个应用，记录版本和相关设置。不要把一次应用内成功，写成对这个来源在所有环境中的结论。
| 想回答的问题 | 合适的起点 |
|---|---|
| 访问者能否在这个网页里观看？ | 目标浏览器中的实际页面 |
| 某个桌面应用能否打开来源？ | 对应的桌面应用 |
| 输入是否像一个正常的 HLS 播放列表？ | 播放列表检查工具 |
| 两个环境为什么结果不同？ | 条件可对照的分步测试 |
浏览器播放也有不同实现
浏览器可能使用内置的 HLS 处理能力，网页播放器也可能在相关媒体接口可用时，使用 hls.js 一类库。支持情况与浏览器、平台和内容有关。不要只凭“某浏览器以前从不支持 HLS”这样的旧印象制定检查方案。
hls.js 项目说明了支持检测与原生播放的不同接入方式。能力检测可以作为起点，但是否满足你的目标，仍要通过实际允许使用的来源完成观看来判断。
解释差异，不要先猜原因
桌面应用和网页可能采用不同的资源请求方式。浏览器路径还会受到页面来源与资源服务器跨域策略的影响。使用 hls.js 的路径时，HLS 资源的响应需要允许相应的跨域请求。
但这不代表所有差异都是 CORS。来源过期、登录条件、媒体支持、网络环境和播放器设置都可能不同。先记录失败发生在哪一步、出现什么提示，再决定排查方向。证据指向跨域时，再进入 CORS 问题页面。
做一次能比较的测试
选择有权测试的来源，记下时间，先在第一个环境播放，再在较接近的时间测试第二个环境。如果链接有效期很短，通过来源所有者提供的正规方式取得等效的新访问权限。
尽量保持来源、账号条件和网络可比较，一次只改一个变量。如果你同时更换了浏览器、网络和视频地址，只能说结果变了，还不能说原因已经定位。
把结果写成别人能接手的话
有用的记录可以是：“来源 A 在应用 X 中播放成功；相同授权来源在浏览器 Z 的页面 Y 中，点击播放后出现以下提示；时间已记录。”需要时附一张经过脱敏的截图。
“这个流没问题，就是浏览器不好”则隐藏了所有条件，只会让下一位排查的人重新开始。
现在就能做的一步
要判断网站是否可用，就在访问者使用的环境里打开 M3U8 播放器，完成主要观看任务。需要补充观察时，再使用浏览器流测试。桌面播放结果用于对照，不替代网页验收。
技术参考
hls.js 官方文档说明了浏览器支持与跨域要求；HTML 媒体规范定义了浏览器媒体元素。本文的选择表属于编辑建议。