video的error事件仅在致命加载或解码失败时触发，如404、跨域拒绝、格式不支持、文件损坏；其触发依据是video.error为非null的MediaError对象，code为1～4分别对应用户取消、网络错误、解码失败、源不可用。

video 标签的 error 事件到底什么时候触发

不是所有播放异常都会触发 error 事件。它只在 video 元素内部发生**致命加载或解码失败**时抛出，比如：资源 404、跨域拒绝、格式不被浏览器支持、媒体文件损坏。网络抖动、短暂卡顿、play() 被用户手势拦截，这些都不会触发 error 事件。

关键判断依据是：video.error 属性是否为非 null —— 它是一个 MediaError 对象，包含 code 字段（1～4），对应不同错误类型。

• code === 1：用户取消了请求（如调用 load() 后立即 abort()）
• code === 2：网络错误（HTTP 状态非 2xx，或连接中断）
• code === 3：解码失败（视频编码不支持、文件截断、容器损坏）
• code === 4：源不可用（src 为空、source 全部不匹配、MIME 类型声明错误）

监听 error 事件的正确写法和常见陷阱

必须在 video 元素插入 DOM 后、设置 src 前就绑定 error 监听器。否则可能错过异步加载阶段的错误（尤其使用 src 属性直接赋值时）。

不要用 onerror 内联属性 —— 它无法访问 event 对象，且不能复用逻辑；也不要只监听一次就认为万事大吉 —— 某些场景（如切换 src）会重置错误状态，需重新监听或复用同一 handler。

立即学习“前端免费学习笔记（深入）”；

const video = document.querySelector('video');
video.addEventListener('error', (e) => {
  console.error('Video error:', video.error?.code, video.error?.message);
  // 注意：video.error 可能为 null，需可选链
});

如何区分是网络问题还是编解码问题

单靠 error.code 不够可靠：Chrome 和 Safari 对 code=2/3 的判定逻辑有差异；某些“格式不支持”错误在部分设备上表现为 code=4。更稳妥的方式是结合上下文诊断：

• 检查 video.currentSrc 是否已解析为有效 URL（若为空，大概率是 source 未匹配或 MIME 错误）
• 用 canPlayType() 预检：例如 video.canPlayType('video/mp4; codecs="avc1.42E01E"') 返回 '' 或 'maybe' 时，实际播放很可能失败
• 抓包确认 HTTP 状态码；用 curl -I 或浏览器 Network 面板看响应头是否含 Content-Type: video/mp4
• 在移动端真机测试：iOS Safari 对 HEVC、AV1 支持有限，Android Chrome 对 WebM/VP9 更友好

error 事件无法捕获的典型情况及替代方案

error 事件对以下情况完全静默：

• 自动播放被阻止（play() 抛出 NotAllowedError）→ 应监听 play 的 Promise 拒绝
• 音视频不同步、花屏、黑帧 → 这类属于解码后渲染异常，需监听 stalled、waiting、emptied 并结合 video.readyState 判断
• DRM 授权失败（如 Widevine）→ 触发 encrypted + mskeyerror（Edge）或 EME API 的 keystatuschange 事件

真正健壮的视频错误处理，得把 error 当作兜底，而不是唯一入口。很多线上项目最终靠组合监听 error、stalled、timeupdate（长时间无更新）、pause（非用户触发）来识别“假死”状态。