上一篇
h5 video的js事件有哪些？h5 video标签常用事件详解
在HTML5的生态体系中,<video> 元素无疑是构建现代网页多媒体体验的核心组件之一，仅仅在页面中嵌入一个视频标签是远远不够的，开发者需要通过JavaScript来精细地控制视频的播放行为、状态监听以及用户交互逻辑，JavaScript为<video>元素提供了一套丰富的事件机制，这些事件构成了视频播放器逻辑的基石，深入理解并熟练运用这些事件，对于实现流畅的用户体验、复杂的播放控制以及性能优化至关重要。
我们需要关注的是与视频加载和准备过程相关的事件,当浏览器开始获取视频数据时，loadstart 事件会被触发，这标志着加载过程的开始，紧接着，如果视频元数据（如时长、尺寸、编码格式等）被成功解析，durationchange 和 loadedmetadata 事件将依次发生，这对于初始化播放器界面尤为重要，我们需要在知道视频总时长后才能正确显示进度条的范围，随后，随着缓冲区的填充，progress 事件会频繁触发，告知开发者当前已下载的数据量，当视频的第一帧数据足以进行播放时，canplay 事件触发，此时用户可以点击播放按钮开始观看，如果视频需要更多的缓冲才能流畅播放，canplaythrough 事件则会在整个视频都能在不中断的情况下播放时触发，这通常用于自动播放策略的判断。
接下来是播放控制层面的核心事件。play 事件在视频开始播放时触发，而 pause 事件则在用户暂停或代码调用暂停方法时触发，这两个事件是同步播放状态的关键，值得注意的是，playing 事件与 play 不同，它表示视频在暂停后重新开始播放，或者在缓冲结束后恢复播放，这意味着视频正在实际输出画面，与之相对的是 waiting 事件，当视频因缓冲不足而暂时停止时触发，此时UI上通常应显示加载动画，一旦缓冲完成，playing 事件再次触发，动画随之消失。
时间轴的变化也是开发者需要重点监控的部分。timeupdate 事件在播放时间发生变化时触发，但其触发频率并不固定，通常每秒触发4到66次不等，不建议在 timeupdate 中进行高频率的计算或DOM操作，以免引起性能瓶颈，如果需要精确控制进度条的拖动或同步显示当前时间，结合 seeking（开始寻找新位置）和 seeked（寻找操作完成）事件会更加稳健。seeking 表示用户正在拖动进度条或代码正在跳转时间点，此时应禁用自动播放或暂停其他逻辑；seeked 则表示跳转完成，视频已定位到新的时间点，可以恢复正常的播放逻辑。
错误处理机制同样不可忽视。error 事件在视频加载或播放过程中发生错误时触发，通过检查 video.error 对象，开发者可以获取具体的错误代码（如MEDIA_ERR_ABORTED, MEDIA_ERR_NETWORK等），从而向用户展示友好的错误提示，而不是让播放器陷入静默失败的状态。ended 事件在视频播放结束时触发，常用于实现“播放下一集”或“重新播放”的功能逻辑。
为了更清晰地梳理这些事件,下表归纳了常用事件及其触发时机：
| 事件名称 | 触发时机 | 典型应用场景 |
|---|---|---|
| loadstart | 开始加载视频数据 | 显示加载提示框 |
| durationchange | 视频时长发生变化 | 初始化进度条总长度 |
| loadedmetadata | 元数据加载完成 | 获取视频宽高，调整播放器容器大小 |
| canplay | 数据足以开始播放 | 启用播放按钮 |
| playing | 视频正在播放中 | 隐藏加载动画，显示暂停按钮 |
| pause | 视频被暂停 | 切换播放/暂停图标 |
| timeupdate | 播放时间更新 | 更新当前时间显示（需注意频率） |
| seeking | 用户开始拖动进度条 | 禁用自动播放，显示缓冲状态 |
| seeked | 拖动结束，定位完成 | 恢复播放逻辑，更新UI |
| ended | 视频播放结束 | 触发结束页或推荐列表 |
| error | 发生错误 | 显示错误提示，记录日志 |
在实际开发中,除了上述基础事件，还有一些高级场景需要特别注意，在移动端浏览器中，由于系统限制，自动播放往往需要用户交互才能触发，监听 play 事件并结合用户手势（如点击）来判断是否允许自动播放是常见的解决方案，对于长视频或直播场景，progress 事件的监听可以帮助实现断点续传或实时进度同步，为了提升性能，应避免在 timeupdate 中直接操作DOM，而是采用防抖（Debounce）或节流（Throttle）技术，或者使用 requestAnimationFrame 来同步UI更新。
JavaScript中的<video>事件体系是一个多层次、多维度的交互网络，开发者需要根据具体的业务需求，合理组合这些事件，既要保证功能的完整性，又要兼顾性能与用户体验，通过细致的事件监听与状态管理，我们可以构建出媲美原生播放器体验的Web视频应用。
相关问答 FAQs
Q1: 为什么在 timeupdate 事件中更新进度条会导致页面卡顿？
A: timeupdate 事件的触发频率取决于浏览器的实现，通常每秒触发多次（例如每秒4到66次），如果在该事件回调中执行复杂的DOM操作、样式计算或网络请求，会频繁触发浏览器的重排（Reflow）和重绘（Repaint），从而消耗大量的CPU资源，导致页面卡顿甚至无响应，建议的做法是：仅在该事件中更新简单的文本显示（如当前时间），对于进度条的视觉更新，可以使用CSS的transition属性配合节流函数，或者使用requestAnimationFrame来确保UI更新与屏幕刷新率同步，从而保证流畅度。
Q2: 如何在视频播放结束后自动播放下一个视频，同时避免在移动端被浏览器拦截？
A: 监听 ended 事件以检测当前视频播放结束，在回调中，你可以加载下一个视频的源并调用 play() 方法，现代浏览器（尤其是移动端Safari和Chrome）为了节省流量和提升体验，通常禁止自动播放带有声音的视频，为了避免被拦截，建议采取以下策略：1. 将下一个视频的 muted 属性设置为 true，静音视频通常允许自动播放；2. 在用户与页面有过一次交互（如点击、触摸）后，再尝试自动播放有声视频；3. 如果必须有声自动播放，可以在用户点击“播放下一集”按钮时显式调用 play()，而不是在 ended 事件中隐式触发，应处理 play() 返回的Promise，捕获 NotAllowedError 异常，并给用户一个明确的提示或提供手动播放的入口。
