先把报告绑定到完整配置
这个方法针对一次给定的媒体配置询问能力。视频配置中可包含内容类型与编码、宽高、码率和帧率；只有“支持某种文件后缀”不足以说明正在检查哪一档视频。记录时还应保留浏览器与设备环境。
为便于阅读，本文把三份已另行保存完整参数的虚构配置简记为A、B、C。这些代号不是清晰度等级，也不是三条网站线路；表中结果只用于演示判断，不能拿来选购设备。
三个布尔字段，各答一个问题
supported表示该配置描述的媒体能否被解码；smooth关注能否按配置帧率播放而无需丢帧；powerEfficient是播放能效提示。它们是不同维度，不是由一到三的评分。false也不是“损坏文件”的统一代号。
在讨论smooth和powerEfficient之前，先看supported。若该配置不受支持，不应只因另外某个字段或页面上一个绿色勾，就把它选为可用方案。字段名称保持原拼写，尤其powerEfficient中的E大写，避免记录时创造另一个不存在的字段。
虚构三行表怎样选，而不是怎样排名
设A返回true、false、false；B返回true、true、false；C返回true、true、true，顺序都是supported、smooth、powerEfficient。若本次要求仅为支持且预计流畅，B和C符合表内条件；A虽能解码，却没有通过这个条件。
若要求再加能效提示为真，表内只剩C。这里得到的是满足所列条件的集合，不是证明C画质最好。B并未因为能效字段为false而变成“不支持”；三个字段的合取条件要按实际任务写出，不能用“总分两分”替代含义。
预测不是一份完成播放的记录
MDN特别提示，在设备统计尚未形成时，浏览器可能把受支持配置报告为smooth与powerEfficient。因此三个true不能当作严格实测认证。即使报告有参考意义，它也没有描述这次文件传输是否及时、完整片段是否成功呈现。
能力报告和实测记录应分开保存。前者写配置、环境、三项返回值；后者另写实际使用的素材、观察区间和发生的现象。遇到不同结果，保留这次差异，不把报告直接改成“浏览器保证不卡”。
配置变化后，旧结果不要自动套用
假设把配置B的帧率从30改为60，新的请求已经不是原来的B。不能因为旧B的smooth为true，就替新配置预填true。分辨率、编码或码率改变时也要保留新配置身份，不只修改一个友好名称。
普通读者无需在陌生站点粘贴代码来做本练习。若已有开发工具或测试报告，先检查参数是否完整、三字段是否原样保留，以及报告是否把预测写成实测。不能支持该API的环境也应标“未取得报告”，而不是伪造三个false。
按这四步完成检查
- 记录被查询的完整配置和环境，给每份配置一个不会混淆的代号。
- 依次读取supported、smooth、powerEfficient，保留三项原值。
- 写明本次需要满足哪些条件，再筛选符合条件的配置，不把布尔项相加排名。
- 把能力预测与实际播放观察分开，参数变化后不沿用旧配置结论。
常见问题
supported为true，smooth就一定为true吗？
不一定。两者回答能否解码与配置帧率下的流畅表现预测两个不同问题。
powerEfficient为false表示文件坏了吗？
不是。它是能效维度，不能用来直接断定文件损坏或完全不支持解码。
三项都true能证明整部视频不卡吗？
不能。它们不是完整播放实测，统计不足时也有实现层面的默认报告行为；实际传输和播放观察需另记。
浏览器没有这个报告怎么办？
记录未取得能力报告，使用已知环境和实际观察补充；不要把缺少报告写成三个false。
资料依据与适用范围
以下资料用于核对文中提到的技术概念和产品操作，不表示这些来源定义或背书“国产在线一卡二卡”这一检索词。界面、地区可用性和产品功能以来源当前说明为准。