timeupdate事件需节流以避免频繁ui更新导致卡顿，可用时间戳闭包实现100ms节流，或结合requestanimationframe实现每帧一次更新，兼顾流畅性与性能。
在 timeupdate 事件中直接更新 UI（比如进度条、当前时间显示）容易因触发过于频繁（每秒可达 4–60 次）导致性能浪费或卡顿。节流（throttle）能限制处理函数的执行频率，让 UI 更新更平滑、更可控。
为什么 timeupdate 需要节流
浏览器对 timeupdate 的触发没有固定间隔，取决于解码速度和帧率，尤其在高码率视频或低性能设备上可能密集触发。若每次都在回调里操作 DOM（如修改 progress.value 或重绘时间文本），会引发大量重排重绘，影响主线程响应。节流不是“阻止更新”，而是“有节奏地更新”——保证视觉连贯性的同时降低开销。
用闭包实现轻量节流函数
无需引入 Lodash，一个简明可靠的节流函数即可：
注意：这里用「时间戳 + 状态标记」方式，比定时器更精准，避免漏掉最后一次关键更新（如播放结束前的 final time）
function throttle(func, delay) {
let lastExec = 0;
return function(...args) {
const now = Date.now();
if (now - lastExec >= delay) {
func.apply(this, args);
lastExec = now;
}
};
}
使用示例：
const video = document.getElementById('myVideo');
const progress = document.getElementById('progressBar');
<p>// 节流后的更新函数（每 100ms 最多执行一次）
const throttledUpdate = throttle(() => {
progress.value = video.currentTime / video.duration * 100;
document.getElementById('currentTime').textContent =
formatTime(video.currentTime);
}, 100);</p><p>video.addEventListener('timeupdate', throttledUpdate);
</p>
结合 requestAnimationFrame 做更顺滑的 UI 同步
如果追求更高帧率一致性（比如动画级进度条），可把节流逻辑与 requestAnimationFrame 结合，确保更新发生在浏览器下一次重绘前：
function throttleRAF(func) {
let scheduled = false;
return function(...args) {
if (!scheduled) {
scheduled = true;
requestAnimationFrame(() => {
func.apply(this, args);
scheduled = false;
});
}
};
}
<p>// 每帧最多更新一次（约 60fps），适合对实时性要求高的场景
video.addEventListener('timeupdate', throttleRAF(() => {
progress.value = video.currentTime / video.duration * 100;
}));
</p>
⚠️ 注意：requestAnimationFrame 版本不控制「最小间隔」，只避免同帧重复执行；若需保底延迟（如防止卡顿下长时间不更新），可叠加时间检查，形成 hybrid 节流。
实际优化建议
- 优先节流 UI 更新，而非业务逻辑：像记录播放位置到 localStorage、上报埋点等非渲染操作，可单独做防抖（debounce）或按需触发，不必和 UI 节流绑死
- 根据场景选延迟值：100ms（10fps）对进度条足够流畅；音频可视化类需求可降到 33ms（30fps）；纯文本时间显示 200–300ms 也完全可接受
- 播放暂停时记得移除监听器或暂停节流：避免无意义调用（虽然节流本身已过滤，但减少事件绑定负担更稳妥）
-
移动端注意 touch 交互冲突：拖动进度条时应临时禁用
timeupdate节流，防止用户拖拽后界面滞后回弹
Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南
