应先判断video.buffered.length > 0再取值，否则会报错；buffered是timeranges对象而非数组，不支持索引访问或foreach；需结合readystate和networkstate判断真实缓冲状态。
video标签的buffered属性怎么读才不踩坑
直接读video.buffered返回的是TimeRanges对象，不是数组——它没有length、forEach这些方法，强行调用会报错。常见错误是写video.buffered[0].start却忽略它可能为空，或误以为video.buffered.end(0)总能拿到值。
- 必须先判断
video.buffered.length > 0，再取video.buffered.end(0) - 弱网下
buffered可能长期为length === 0，此时不能靠它估算进度，得结合video.readyState和video.networkState - 注意Safari对
buffered更新有延迟，尤其在seek后，需监听timeupdate事件再读取
MediaSource如何避免appendBuffer失败导致卡死
SourceBuffer.appendBuffer()失败不会抛异常，而是触发sourcebuffer.onerror，但更隐蔽的问题是：连续追帧失败时，updating状态卡住，后续append被静默丢弃，播放器看起来“不动了”。
- 每次
appendBuffer前检查sourceBuffer.updating === false，否则等待updateend事件 - 监听
sourceBuffer.onupdateend，若1秒内没触发，主动abort()并重置timestampOffset - 弱网下append前做轻量校验：二进制数据头是否匹配fMP4（如
data.slice(0, 4).toString() === 'ftyp'），避免无效数据污染buffer
弱网下如何用networkState和readyState做真实状态判断
video.networkState和video.readyState比单纯监听error或stalled更早暴露问题，但它们的取值逻辑容易误解。
-
networkState === 0（NETWORK_EMPTY）只在刚创建或src设空时出现；真正弱网卡顿时，通常是networkState === 2（NETWORK_NO_SOURCE）或反复在1（NETWORK_IDLE）和3（NETWORK_LOADING）间跳变 -
readyState === 2（HAVE_METADATA）不代表能播——它只说明已解析出宽高/时长，但buffer可能仍是空的；要播起来至少得readyState >= 3（HAVE_FUTURE_DATA） - 当
readyState === 0且networkState === 3持续超3秒，基本可判定服务端响应异常，应切换备用源而非等重试
preload="metadata"在弱网下为什么反而加重卡顿
设preload="metadata"会让浏览器只请求视频头部（moov box），但弱网下这个小请求也可能卡住，阻塞后续JS执行，且无法取消——它不像fetch能用AbortController中断。
- 首屏关键视频建议
preload="none"，等用户交互（如点击播放按钮）再手动load() - 非首屏视频统一用
loading="lazy"，配合IntersectionObserver检测进入视口后再设置preload="metadata" - 如果必须预加载metadata，用fetch+Blob模拟：先fetch视频URL的
Range: bytes=0-1024，解析moov后手动创建MediaSource，绕过原生preload机制
buffered为空、updating卡死、networkState反复跳变时，敢用abort()、敢清空SourceBuffer、敢放弃当前分片去拉低码率源——这些动作没有文档教，全靠对底层状态的理解和实操勇气。前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
