TimeRanges 是浏览器维护的只读对象，表示媒体元素已缓存的时间区间集合，由多个离散、可能不连续的[start, end)秒级区间组成，length 返回区间数量，需遍历匹配 currentTime 才能准确获取有效缓冲范围。
HTML5 的 TimeRanges 对象是理解视频/音频缓冲行为的关键，它不是简单的一段“已加载百分比”，而是一组**离散、可能不连续的时间区间集合**。掌握它，才能准确绘制缓冲进度条、判断能否无缝跳转、或诊断卡顿原因。
TimeRanges 是什么？不是单个范围，而是时间区间的列表
TimeRanges 是一个只读接口对象，由浏览器内部维护，用于描述当前媒体元素（video 或 audio）中哪些时间段的数据已被缓存到内存或本地缓冲区。它的核心特征是：
- 它不保证从 0 开始连续——尤其在用户拖动进度条后，浏览器通常只缓存“当前播放点之后的一段”，形成多个孤立区间
- 每个区间由
start(index)和end(index)定义，单位为秒（浮点数），例如buffered.start(0) === 12.5表示第一段缓存从第 12.5 秒开始 -
buffered.length返回当前有多少个独立区间，可能为 0（尚未开始缓冲）、1（常见于初始加载）、或大于 1（如拖拽后产生多段）
如何安全读取当前有效的缓冲区间？
直接取 buffered.start(0) 往往不可靠，因为第一段可能早已被播放完、甚至被浏览器释放。更实用的做法是：从当前播放位置出发，找**紧邻其后且最近的缓冲结束点**。
推荐逻辑如下：
立即学习“前端免费学习笔记（深入）”；
- 监听
progress事件（每当缓冲更新时触发） - 遍历
buffered所有区间，从最后一个开始向前查（即i = buffered.length - 1递减） - 找到第一个满足
buffered.start(i) <= currentTime && buffered.end(i) > currentTime的区间——说明当前正在播放的部分已被缓存 - 若未找到，则继续向后找下一个可缓冲的区间起点，即
buffered.start(j)中最小的、且大于currentTime的值
这能避免因区间顺序混乱或已过期导致的误判，是实现“真实缓冲条”的基础。
buffered 与 played、seekable 的区别必须分清
这三个属性都返回 TimeRanges 类型，但语义完全不同：
-
buffered：浏览器实际已下载并暂存在内存中的时间段（受网络、preload 策略、播放行为影响） -
played：用户已经实际播放过的时间段（只增不减，即使暂停后重播也不重复计入） -
seekable：当前可随机跳转（seek）的时间范围——取决于服务器是否支持 HTTP Range 请求；若返回空（length === 0），说明该视频不支持拖拽
例如：一个未开启 range 支持的 MP4 文件，seekable.length 可能为 0，即使 buffered.length 是 1；而直播流常出现 played.length > 0 但 buffered.length === 0（边播边丢，不缓存历史）。
影响 TimeRanges 行为的关键因素
缓冲区的实际表现不是固定不变的，以下设置和环境会显著改变 buffered 的结构与长度：
-
preload属性：none时几乎无缓冲；metadata仅加载头信息（时长、宽高），auto则由浏览器策略决定（现代浏览器通常按需缓冲，而非全量加载） - 用户交互：拖动进度条（
currentTime赋值）会触发新范围请求，生成新的TimeRanges区间 - 网络条件：弱网下浏览器可能主动截断缓冲长度，优先保障当前播放流畅，表现为
buffered.end(i)停在离currentTime很近的位置 - 服务端响应：必须返回
Accept-Ranges: bytes头，客户端才可能发起分片请求，从而形成多段TimeRanges
不依赖 Flash 时代那种“预加载全部”的假设，是理解现代 HTML5 缓冲机制的前提。
