不能单靠readyState监测网络波动，需结合waiting/playing事件、networkState和时间阈值判断真实卡顿：waiting且未paused表明缺数据，networkState===2且readyState
不能单靠 readyState 直接“监测网络波动”，但它能帮你识别卡顿是否由数据不足引发——关键在于结合事件、networkState 和播放行为做交叉判断。
用 readyState + waiting/playing 识别真实卡顿
移动端视频画面停住但没报错，很可能是缓冲中断。此时 paused === false，但实际无新帧渲染。可靠信号是：
-
触发
waiting事件且video.paused === false：说明正在播放中突然缺数据，大概率是网络抖动或带宽下降 -
触发
playing事件：表示从等待恢复，可关闭加载提示 - 仅看
readyState数值容易误判——比如从 3 降到 2 可能只持续几十毫秒，人眼无感；但若卡在readyState 超过 800ms，就该视为异常卡顿
必须搭配 networkState 排除假阳性
readyState 低不一定是网络问题，也可能是资源未加载或解析失败。查 networkState 快速归因：
-
networkState === 0（NETWORK_EMPTY）：视频元素刚创建，src还没设，不是网络问题 -
networkState === 2（NETWORK_LOADING）：确实在下载，配合readyState 就能确认是加载慢导致卡顿 -
networkState === 3（NETWORK_NO_SOURCE）：地址无效或跨域失败，和网络波动无关，需检查链接或 CORS 配置
加一层时间阈值过滤抖动噪声
网络轻微波动会让 readyState 在 2↔3 间跳变，直接响应会频繁闪动 UI。建议：
立即学习“前端免费学习笔记（深入）”；
- 监听
waiting后，启动一个 600ms 计时器；如果期间没触发playing，再判定为“卡顿”并显示提示 - 用
setInterval每 300ms 检查一次：if (!video.paused && video.readyState ，连续 2 次命中即告警 - 避免轮询太密——移动端 CPU 和电量敏感，300ms 是平衡响应与开销的合理间隔
补充参考：用 navigator.connection 辅助预判
虽然不能实时反映当前波动，但能提前规避风险：
- 监听
navigator.connection.change，当effectiveType从'4g'变成'2g'，可主动降级视频清晰度或预加载更小分片 - 结合
downlink值（如 - 注意：Safari 对该 API 支持有限，需降级到
navigator.onLine保底
