html5媒体元素error事件是捕获播放中断的唯一标准入口，但需结合readystate、networkstate、stalled等状态交叉验证code=1~4的真实原因，避免误判静默失败，并结构化日志字段以精准定位问题。
HTML5 媒体元素（<video></video> 或 <audio></audio>）的 error 事件是捕获播放中断的**唯一标准入口**，但直接监听 event 并检查 error.code 容易误判。真正“精准”捕获，关键在于**不依赖 error.code 单一值，而是结合运行时状态、事件链和上下文做交叉验证**。
必须绑定 error 事件并立即检查 error 对象是否存在
很多开发者忽略一个前提：mediaElement.error 是惰性属性，仅在 error 事件触发后才可能有值，且该值只在本次错误生命周期内有效。因此处理逻辑必须：
- 在
error回调中第一行就判断if (!mediaElement.error) return - 不能缓存
error对象供后续使用，也不能在其他事件（如play）里读取它 - 避免用
console.log(event)代替实际读取mediaElement.error.code——因为 event 对象本身不包含 code
区分四类 error.code 的真实含义，避开常见误报
MediaError.code 只有 1–4 四个合法值，但每个值对应的行为差异很大：
-
code = 1（MEDIA_ERR_ABORTED）：不是故障，是流程中止。比如用户点击暂停后刷新页面、或脚本调用
load()紧接着pause()。此时networkState === NETWORK_LOADING或readyState === 0，应归为 user_abort 类型，不上提示，仅上报日志 -
code = 2（MEDIA_ERR_NETWORK）：需配合网络层信号确认。检查 Network 面板该资源是否返回 404/403/0 状态码；同时验证
networkState === NETWORK_NO_SOURCE。若为 0 状态码，大概率是广告屏蔽插件拦截或 CORS 预检失败 -
code = 3（MEDIA_ERR_DECODE）：最易误判。必须同时满足：
error.code === 3+readyState ≤ HAVE_METADATA+networkState === NETWORK_NO_SOURCE。否则可能是已开始播放后的卡顿或 stalled，而非解码失败 -
code = 4（MEDIA_ERR_SRC_NOT_SUPPORTED）：不是文件问题，而是所有
<source></source>的canPlayType()返回空字符串。应遍历每个 source，调用canPlayType(type)并显式比对结果，而非只看 MIME 类型声明
捕获静默失败：那些不触发 error 事件的中断
某些关键中断根本不会走 error 事件，必须靠其他信号主动探测：
-
自动播放被拒：Chrome/Safari 在无用户手势时调用
play()会 Promise reject，但不触发error。此时paused === true且readyState === 0是明确信号 -
持续 stalled：监听
stalled事件，若连续触发 2 次以上，且buffered.length === 0或buffered.end(0) - currentTime 持续超 3 秒，标记为 <code>stall_experience_degraded -
播放卡死：暂停后
currentTime超 5 秒未更新，或playing事件后长时间无timeupdate，可记录为playback_hang
结构化日志是精准定位的前提
单条 “play failed” 日志毫无价值。每次捕获异常，至少附带以下字段：
-
媒体标识：业务侧定义的
audio_id或video_id（如"lesson-202610-intro"），不用 URL 或 DOM ID -
环境快照：
browser.name + version、os.name、is_mobile、muted状态 -
加载状态：
readyState、networkState、buffered.length、是否已触发loadedmetadata -
触发路径：自动播放 / 用户点击 / API 调用；是否发生在
visibilitychange后或页面恢复前台时
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
