html5媒体播放关键在于浏览器对mime类型与编码组合的解码能力，而非文件扩展名或标签；需用canplaytype()检测但不可全信，应结合事件监听、多格式fallback、服务端正确content-type配置及移动端特殊限制（如playsinline、用户手势触发等）综合保障兼容性。
HTML5 媒体资源能否正常播放，不只看文件后缀或是否用了 <video></video> 标签，关键在于浏览器能否识别并解码该资源的 MIME 类型与编码组合。单纯靠文件扩展名（如 .mp4）判断兼容性容易出错——比如一个 .mp4 文件可能封装了 H.265（HEVC）视频流，而多数旧版浏览器根本不支持解码。
准确检测 MIME 类型支持：别只信 canPlayType()
canPlayType() 是唯一标准接口，但它不是“播放开关”，而是浏览器对解码能力的静态推测：
-
返回 ""：明确不支持，比如传
video/mp4; codecs="av01.0.05M.08"给未启用 AV1 解码器的 Chrome -
返回 "probably"：容器和编码都匹配已验证组合，如
video/mp4; codecs="avc1.42E01E, mp4a.40.2"（H.264 Baseline + AAC-LC） -
返回 "maybe"：信息不足，例如只写
video/mp4没带 codecs 参数——实际大概率播不了
注意：即使返回 "probably"，也不能保证真能播。移动端（尤其华为、小米定制浏览器）常拦截非 H.264 视频；iOS Safari 还额外要求 playsinline 和用户手势触发。真正可靠的信号是 canplay 或 loadedmetadata 事件触发。
多格式 fallback 的正确写法
不要只提供一种 <source></source>，也不要把 canPlayType() 结果当最终结论。应按兼容优先级组织源列表：
-
video/mp4; codecs="avc1.42E01E, mp4a.40.2"—— 最广兼容，首选 -
video/webm; codecs="vp9, opus"—— 现代浏览器体积更小，适合 Chrome/Firefox/Android -
video/ogg; codecs="theora, vorbis"—— 仅作保底，Safari 已基本弃用
动态插入 <source></source> 并监听 error 事件：若第一个源加载失败，自动切换到下一个。这样既利用了浏览器原生选择逻辑，又避免了单点失效。
服务端与客户端必须协同
就算格式和编码全对，如果服务器返回错误的 Content-Type，视频照样加载失败：
- MP4 文件应返回
video/mp4 - WebM 文件应返回
video/webm - Ogg 文件应返回
video/ogg
Apache 可通过 AddType 配置，Nginx 用 types 块，CDN 也要检查 MIME 映射是否生效。用开发者工具 Network 面板查看响应头中的 Content-Type，确认与实际文件类型一致。
移动端特别要绕开的坑
iOS Safari 对视频播放加了三道硬约束，和 MIME 类型无关但常被误判为兼容问题：
- 必须设置
playsinline属性（否则强制全屏） - 播放操作必须由用户手势（click/touchend）触发
- 若未静音，需显式设
muted，或等待用户授权
这些限制在桌面模拟器里测不出来，务必在真机上验证。尤其注意：Safari 15+ 开始支持 WebM，但 iOS 14 及更早仍只认 MP4+H.264，不能靠 UA 判断，要用 canPlayType() 实际检测。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
