直接操作原生video元素即可控制播放：play()和pause()需用户手势触发；currentTime、volume、muted可读写；用timeupdate事件更新进度条更高效；拖拽时用标志位抑制seeking事件；注意iOS/Safari/安卓WebView兼容性细节。

如何用 JavaScript 控制 元素的基本播放行为

直接操作原生 元素是最轻量、兼容性最好的起点。所有控制都基于 DOM API，不需要第三方库。

• play() 和 pause() 是最常用方法，但注意：现代浏览器要求用户手势触发（如点击）后才能调用 play()，否则会抛出 NotAllowedError
• currentTime 可读写，单位是秒（支持小数），设值后不会自动播放，需额外调用 play()
• volume 范围是 0–1，设为 0 即静音；muted 是布尔值，设为 true 会强制静音且绕过某些自动播放限制
• paused、ended、seeking 等属性可用于判断状态，比监听事件更即时

为什么自定义控件要监听 timeupdate 而不是轮询 currentTime

timeupdate 事件在视频播放过程中由浏览器按需触发（通常每 250ms 左右一次），比 setInterval 轮询更省资源、更准确。手动轮询不仅浪费 CPU，还可能因帧率波动导致进度条跳变或卡顿。

• 事件触发频率取决于浏览器实现和硬件性能，不能假设固定间隔
• 暂停/拖拽时 timeupdate 会停止触发，天然适配状态变化
• 如果需要更高精度（如音频可视化），应结合 requestAnimationFrame + currentTime，而非增加事件监听频率

const video = document.querySelector('video');
video.addEventListener('timeupdate', () => {
  const progress = (video.currentTime / video.duration) * 100;
  progressBar.style.width = `${progress}%`;
});

拖拽进度条时如何避免 seeking 和 seeked 事件误触发

用户拖动自定义进度条时，如果直接设置 video.currentTime，浏览器会立即触发 seeking → seeked，这可能导致 UI 闪烁或重复更新。关键是在拖拽中抑制非必要响应。

• 用 mousedown + mousemove 实现拖拽，期间设一个标志位（如 isSeeking = true）
• 在 timeupdate 或 seeking 的监听器里先检查该标志，为 true 时跳过 UI 更新
• 拖拽结束（mouseup 或 mouseleave）后清标志，并手动触发一次 UI 同步
• 注意移动端要用 touchstart/touchmove 替代鼠标事件

自定义播放器必须处理的三个兼容性细节

不同浏览器对 的底层实现有差异，以下三点不处理就会在 Safari、iOS 或旧版 Edge 上出问题：

• canplaythrough 事件在 iOS Safari 中可能不触发，建议降级监听 canplay 并配合 readyState >= 3 判断
• Safari 不支持 play() 返回 Promise，需用 .catch(() => {}) 捕获拒绝，但不要依赖返回值做后续逻辑
• 部分安卓 WebView 对 webkitRequestFullscreen() 响应异常，应优先用标准 requestFullscreen()，并 fallback 到宽高样式模拟全屏

复杂点往往藏在这些边界里：比如用户点了播放按钮却没反应，大概率是 play() 被静默拒绝；进度条拖完卡住不动，可能是 seeked 没等来就提前更新了 UI。动手前先确认目标环境的限制，比堆功能更重要。