onwaiting事件在媒体播放因缓冲不足而暂停时触发，常见于网络变慢、缓存耗尽、清晰度切换后新分片未加载到位等场景，不反映加载进度，仅表示播放中断等待。
onwaiting 事件什么时候会触发
onwaiting 是 HTML5 <video> 和 <audio> 元素的原生事件，当媒体播放因缓冲不足而暂停时触发——不是“开始加载就触发”，也不是“加载完成才触发”，而是“正播着，突然卡了，浏览器决定等会儿再播”那一瞬间。
常见触发场景包括：
- 网络变慢，已缓存数据耗尽，播放器主动暂停等待新数据
- 切换清晰度后，新分片未及时加载到位
- 使用
preload="metadata"或preload="none"时，首次play()后立即触发（因为没预加载足够内容）
注意：onwaiting 和 onloadstart、onprogress 不同，它只关心“播放中断等待”，不反映加载进度本身。
怎么监听和响应 onwaiting
直接在元素上绑定或用 JS 添加监听均可，但推荐用 addEventListener，避免覆盖已有处理逻辑：
立即学习“前端免费学习笔记（深入）”；
<video id="myVideo" src="demo.mp4"></video>
<script>
const video = document.getElementById('myVideo');
video.addEventListener('waiting', () => {
console.log('正在缓冲，当前时间：', video.currentTime);
// 可在此显示 loading 提示、禁用控制按钮等
});
</script>
关键点：
- 不要用
onwaiting="handleWaiting()"内联写法，容易被其他脚本覆盖 - 事件触发时，
video.readyState通常为HTMLMediaElement.HAVE_CURRENT_DATA（2）或更低，video.buffered可能为空或范围收缩 - 不要在此事件里反复调用
play()，否则可能形成“等待→play→又等待→再play”的死循环
onwaiting 和 oncanplaythrough 的关系别搞反
oncanplaythrough 表示“预计能播完，不用中途停顿”，但它不保证后续一定不触发 onwaiting。网络波动、服务端限速、CDN 节点切换都可能导致后续再次缓冲。
所以：
- 不要用
oncanplaythrough作为“播放绝对稳定”的信号 - 显示“缓冲中”状态时，应同时监听
waiting和playing，并在playing触发时清除提示 - 如果你发现
onwaiting频繁触发（比如每秒一次），大概率是服务器未正确支持 HTTP Range 请求，导致浏览器无法按需加载片段
移动端兼容性和实际表现差异
iOS Safari 对 onwaiting 的触发非常保守——多数情况下根本不会触发，尤其在自动播放受限、用户未交互前，媒体元素处于“挂起”状态，连 loadedmetadata 都可能延迟。
Android Chrome 相对正常，但要注意：
- 使用
preload="auto"在移动网络下可能被浏览器忽略（省流量策略） - 某些 WebView（如微信内置）会屏蔽或延迟
waiting事件 - 若依赖该事件做 UI 反馈，务必加 fallback：例如设置定时器检查
video.paused && video.readyState < 4作为兜底判断
真正难的不是写监听，而是判断“这到底是真卡了，还是只是 iOS 假装没卡”。
