应为video标签提供多格式source并按兼容性排序，优先webm（VP9）、其次mp4（明确avc1.64001f编码）、最后mov；避免依赖canPlayType()，须监听error事件并设置img+下载链接兜底。
浏览器报错 VIDEO_ERROR_SRC_NOT_SUPPORTED 怎么办
这是最常见的视频加载失败信号，说明当前浏览器无法解码你提供的 src 格式。HTML5 视频本身不决定支持哪些编码，而是由浏览器底层媒体引擎（如 Chromium 的 FFmpeg、Safari 的 AVFoundation）决定。直接只写一个 .mp4 文件，Safari 可能行，Firefox 可能黑屏，iOS 旧版甚至拒绝播放 H.265 编码的 MP4。
用
核心是让浏览器自己选它能播的——不是靠 JS 判断 UA，而是靠原生 的格式协商机制。顺序很重要：浏览器从上到下尝试，遇到第一个能解码的就停。
-
webm（VP9）在 Chrome/Firefox/Edge 中兼容性最好，体积小，推荐放第一 -
mp4必须明确写codecs参数，avc1.64001f表示 Baseline Profile H.264，iOS/iPadOS/macOS Safari 全系支持；避免用 High Profile（如avc1.640028），老 iOS 会拒播 -
quicktime（.mov）仅对 Safari 有效，且仅限 H.264 Baseline 编码，不要指望它救火 Android 或 Firefox
为什么不能只靠 JavaScript 检测 canPlayType()
这个 API 返回的是“可能支持”，不是“确定能播”。比如 video.canPlayType('video/mp4; codecs="avc1.64001f"') 在 Safari 上可能返回 "maybe"，但实际加载后仍报错——因为文件里混入了不兼容的音频轨道（如 AAC-HE），或容器时间戳异常。
- 别用
canPlayType()做唯一判断依据，它只是预检，不是运行时保证 - 必须监听
error事件，配合loadstart和loadedmetadata才能确认真实状态 - 移动端尤其要注意：iOS Safari 对自动播放、跨域资源、非用户手势触发的
play()都有强限制，错误可能来自策略而非格式
兜底方案：显示静态图 + 下载链接
当所有 error 事件触发后，最务实的做法不是弹窗或重试，而是降级为可访问的静态内容。
立即学习“前端免费学习笔记（深入）”；
注意：
必须写在 内部，作为 fallback 内容；外部包裹的提示文字不会被读屏软件识别，也不参与语义化渲染。
真正容易被忽略的是音频轨道和字幕轨的兼容性——哪怕视频能播，如果用了 AC-3 音频或 VTT 外挂字幕路径跨域，依然会静音或无字幕。格式只是第一道门。
