canPlayType只是浏览器对格式支持的轻量级推测，非真实播放验证；返回""、"probably"、"maybe"三种值，分别表示明确不支持、参数匹配但未必能播、参数模糊；实际应以loadedmetadata、canplay、error等事件为准，并按兼容性顺序检测source fallback。
canPlayType 方法不是“能不能播”的判决器，而是浏览器对格式支持能力的一次轻量级推测。它快、不加载文件、不触发网络请求，但返回结果只是静态评估，不能代替真实播放验证。
返回值的真实含义
调用 video.canPlayType(type) 后，只可能得到三种字符串：
-
""（空字符串）：浏览器明确不支持该 MIME 类型与编解码器组合，比如向旧版 Firefox 传
"video/mp4; codecs=\"av01.0.05M.08\""； -
"probably"：容器格式（如 mp4）和编码参数（如
avc1.42E01E）都匹配已知稳定解码器声明，例如 Safari 对"hev1.1.6.L93.B0"常返回这个，但不代表真能解码； -
"maybe"：参数不完整或模糊，比如只写
"video/webm"没带codecs，或大小写/空格不规范（"vp9"和"VP9"可能结果不同）。
为什么“probably”不等于“能播”
这个方法不加载文件、不试解码、不查硬件能力，仅查浏览器内部注册的解码器白名单。实际播放中常见黑屏、卡在 stalled 状态，或报错 MEDIA_ERR_DECODE，尤其在国产定制浏览器（华为、小米）或部分 Android 设备上——它们可能虚假声明支持 AV1 或 HEVC，实则拦截播放。
- iOS Safari 要求
playsinline+ 用户手势触发 + 静音才允许播放，这些限制和 canPlayType 无关，但常被误判为格式问题； - Firefox 目前仍不支持 HEVC，哪怕检测返回
"probably"，实测必失败； - 返回
"maybe"的格式，实际成功率往往低于 30%，不应作为主力 fallback 选项。
怎么用才靠谱
把 canPlayType 当作第一道快速筛子，而非最终结论。真正可靠的信号是事件： loadedmetadata（元数据就绪）、canplay（首帧可渲染），以及 error（加载或解码失败）。
立即学习“前端免费学习笔记（深入）”；
- 按兼容性优先级顺序检测：
"video/mp4; codecs=\"avc1.42E01E, mp4a.40.2\""→"video/webm; codecs=\"vp9, opus\""→"video/mp4; codecs=\"av01.0.05M.08\""； - 检测后生成
<source></source>列表，让浏览器原生选择第一个可用项，不要手动赋值src后再调load()； - 必须监听
error事件，首个<source></source>失败时自动切换到下一个，形成闭环 fallback； - 对关键场景（如视频地图、实时监控），服务端可结合 JS 探测结果下发适配资源，避免客户端反复加载失败。
绕不开的细节陷阱
写错一个字符，canPlayType 就会返回空字符串：
- H.265 推荐用
"hev1.1.6.L93.B0"或"hvc1.1.2.L153.B0"，profile/level/tier 超出设备能力范围会失效； - AV1 必须是
"av01.0.05M.08"（数字 0，非字母 O），引号必须是英文双引号，codecs内不能有空格； - 不要混用文件扩展名和 MIME 类型判断，
.mp4文件若用video/ogg声明，结果一定为空； - IE8 及更早版本不支持该方法，需先做
canPlayType in videoEl特性检测。
