video.buffered 返回的是浏览器已缓冲的视频时间区间（单位：秒）组成的 timeranges 对象，可能包含多个不连续片段；需遍历区间找出覆盖 currenttime 的那段并计算其 end 与 duration 的百分比，而非直接用 end(0)。
video.buffered 返回的是什么时间范围
video.buffered 是一个 TimeRanges 对象，不是简单的百分比数值。它记录浏览器已缓冲的视频时间区间（单位：秒），可能包含多个不连续的片段（比如用户跳播后形成两段缓冲区）。直接取 video.buffered.length 不能反映“进度”，必须计算已缓冲总时长占 video.duration 的比例。
用 buffered.end(0) 获取当前连续缓冲终点的陷阱
很多代码直接写 video.buffered.end(0)，这仅适用于**从开头连续缓冲**的情况。一旦用户拖动进度条或网络中断重连，video.buffered 可能有多个区间（length > 1），此时 end(0) 返回的是第一个区间的结束时间，完全不反映当前播放位置附近的缓冲状态。
- 正确做法是遍历所有区间，找出覆盖当前播放时间
video.currentTime的那个区间，再取它的end - 若没有区间覆盖当前时间（比如刚拖动完、尚未开始缓冲），则缓冲百分比为 0
- 示例逻辑：
function getBufferedPercent(video) {
const time = video.currentTime;
let bufferedEnd = 0;
<p>for (let i = 0; i < video.buffered.length; i++) {
if (video.buffered.start(i) <= time && time <= video.buffered.end(i)) {
bufferedEnd = video.buffered.end(i);
break;
}
}</p><p>return video.duration ? Math.min(100, (bufferedEnd / video.duration) * 100) : 0;
}监听 bufferedupdate 事件不如用 timeupdate + 定期检查
buffered 属性本身不会触发事件，bufferedupdate 并非标准事件（Chrome 曾短暂支持但已移除）。可靠方案是监听 timeupdate，并在其中调用缓冲计算函数；或者用 setInterval 每 200–500ms 主动检查一次 —— 尤其在静音/暂停状态下，timeupdate 可能不触发，但缓冲仍在进行。
- 避免高频计算：不用
requestAnimationFrame，间隔低于 100ms 意义不大且增加开销 - 注意
video.duration初始为NaN，需等loadedmetadata或canplay事件后才可用 - 移动端 Safari 对
buffered的更新有时滞，建议结合readyState判断（readyState >= HTMLMediaElement.HAVE_FUTURE_DATA）增强可靠性
实际应用中容易忽略的边界情况
真实场景下缓冲百分比会频繁抖动，直接用于 UI 进度条会造成闪烁。需要做简单平滑处理：
立即学习“前端免费学习笔记（深入）”；
- 对连续多次计算结果取移动平均（如最近 3 次的平均值）
- 当
bufferedEnd小于currentTime时，说明已缓冲区域落后于播放点 → 实际卡顿风险高，此时应返回 0 而非负数 - 直播流（
duration === Infinity）无法用百分比，只能用buffered.length和buffered.end(i) - currentTime计算“可回溯秒数”
缓冲不是线性过程，网络波动、CDN 节点、MSE 分段加载都会影响 buffered 的表现。别把它当成精确指标，而是作为用户体验的辅助参考 —— 用户真正感知的是是否卡顿，不是数字本身。
