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（非用户触发）来识别“假死”状态。
