HTML5视频错误处理需分类型响应：code=1不提示，code=2用fetch探测后指数退避重试，code=3降级备用源，code=4切换<source>；结合networkState、readyState等状态验证，联动格式/码率降级与可操作反馈。
HTML5 视频加载错误处理与重试机制，核心在于“分类型响应”而非统一重试。错误不是故障信号，而是上下文线索——需结合 error.code、networkState、readyState 和设备能力交叉判断，再触发对应动作。
准确识别错误根源，避免误判
仅监听 error 事件并展示数字码（如 “Error 2”）毫无意义。必须读取 video.error?.code 并结合其他状态做验证：
- code = 1（MEDIA_ERR_ABORTED）：用户主动中断（如跳转页面、关闭标签页），不提示、不上报 UI，仅记录日志
-
code = 2（MEDIA_ERR_NETWORK）：需立即用
fetch(url, { method: 'HEAD' })探测是否为 404/403 或连接超时；若返回非 2xx，则重试无效，应提示登录或换源 - code = 3（MEDIA_ERR_DECODE）：大概率是文件损坏或编码异常，重试无用，应降级到备份源或提示刷新页面
-
code = 4（MEDIA_ERR_SRC_NOT_SUPPORTED）：格式全不支持，需跳过当前
<source>，尝试下一个兼容格式（如 AV1 → VP9 → H.264） - 补充验证：
video.networkState === HTMLMediaElement.NETWORK_NO_SOURCE表明所有<source>都未匹配；stalled持续超 3 秒且buffered.length === 0，说明首帧卡死，归为网络问题
按错误类型执行差异化重试
重试不是兜底操作，而是有约束的恢复动作：
- 对 网络类错误（code=2）：启用指数退避，建议最多 3 次（延迟 500ms → 1s → 2s），每次重试前检查
navigator.onLine，并附加时间戳参数（如?t=1719281160）绕过 CDN 缓存 - 对 格式不支持（code=4）：不重试同一地址，而是切换
<source>顺序，移除不兼容项的src属性防止干扰 - 对 解码失败（code=3）：直接降级至备用源（如从高清 MP4 切至低清 MP4），不重复加载原资源
- 对 用户中止（code=1）：不重试，也不反馈，避免打扰
多层降级与弱网适配联动
容错路径应在加载前就设计好，而非出错后才补救：
立即学习“前端免费学习笔记（深入）”；
-
格式降级：在
<video>中按兼容性排序<source>，例如av1.webm→vp9.webm→h264.mp4；iOS Safari ≤14 主动禁用 WebM 源 -
码率降级：检测
navigator.connection.effectiveType为'2g'或'slow-2g'时，跳过高码率源，直切 360p MP4，并轻量提示“已切换至流畅模式” - 兜底 fallback：所有自动策略失效后，提供“手动选择清晰度”入口，列出当前可用源（含格式标识，如 “MP4(H.264)”），并内置“复制视频地址”供用户外链验证
给用户可感知、可操作的反馈
技术决策要透明化，但不能暴露复杂逻辑：
- 网络重试中显示轻量提示：“正在重连…”而非黑屏等待
- 重试失败后展示带「重试」按钮的 toast，点击即执行
video.load() + video.play()，并清除缓存 - iOS Safari 中
play()被静音策略拦截时，readyState === 0且paused === true，需单独提示“请手动点击播放并允许声音” - 所有操作均记录
performance.mark()与错误类型，用于后续优化策略权重
