17370845950

HTML5音视频进度控制需用currentTime和duration，但必须等loadedmetadata事件后才能读取duration；用type="range"实现拖拽条时，应监听input和timeupdate事件同步值，并用seeking/seeked事件精准判断寻道状态。

用 currentTime 和 duration 手动控制视频/音频进度

HTML5 原生的 和 元素不自带可拖拽的进度条 UI，但提供了完整的底层控制能力。核心是读写 currentTime（当前播放位置，单位秒）和只读的 duration（总时长，单位秒）。注意：必须等元数据加载完成（loadedmetadata 事件触发后）才能可靠读取 duration，否则可能为 NaN。

• currentTime 可写，赋值会跳转到对应时间点，但若媒体尚未加载该位置数据，会触发缓冲（表现为短暂卡顿或 waiting 事件）
• 设置 currentTime 后，元素会自动触发 timeupdate 事件，可用于同步 UI 进度条
• 在移动端 Safari 中，部分格式（如未分片 MP4）可能禁止非用户手势触发的 currentTime 设置，需确保操作来自 click 或 touchend

用 input type="range" 实现可拖拽进度条

原生 是最轻量、无障碍友好、且无需额外样式兼容的进度条控件。关键在于同步其 value 与媒体的 currentTime，并处理拖拽过程中的实时更新。

• 初始时，设 max 属性为 media.duration（需等待 loadedmetadata），value 为 media.currentTime
• 监听 input 事件（非 change）——它在拖拽过程中持续触发，能实现“边拖边播”效果
• 在 input 回调中直接赋值 media.currentTime = range.value，但要加 isNaN(media.duration) 防御判断
• 同时监听 timeupdate 事件，反向更新 range.value = media.currentTime，保持 UI 与播放状态一致

为什么 seeking 和 seeked 事件比单纯监听 timeupdate 更可靠

当用户拖动进度条或脚本调用 currentTime 时，浏览器实际执行的是“寻道（seeking）”操作。这个过程有明确的状态边界：seeking 表示开始寻道，seeked 表示寻道完成且已定位到目标时间点。仅靠 timeupdate 容易误判——比如播放中自然推进也会触发它，无法区分“用户主动跳转”和“正常播放”。

• seeking 触发时，video.readyState 通常降为 0（HAVE_NOTHING），此时不应更新 UI 进度条，避免出现“倒退”假象
• seeked 触发时，video.currentTime 已稳定为目标值，是更新 UI 的安全时机
• 若需显示加载中状态（如 spinner），应在 seeking 时显示，在 seeked 或 canplay 时隐藏

移动端 iOS Safari 的进度控制特殊限制

iOS Safari 对自动播放和非交互式媒体控制做了严格限制。即使页面已获得用户手势授权，以下情况仍可能导致 currentTime 赋值失败或静音：

立即学习“前端免费学习笔记（深入）”；

• 媒体未设置 muted 且未显式调用 play()（iOS 要求首次播放必须由用户手势触发）
• 在 autoplay 属性开启但未加 muted 的视频上，currentTime 设置会被忽略，且不报错
• 使用 input[type="range"] 拖拽时，若未在 touchstart 或 click 中提前调用过 play()，首次拖拽可能无响应
• 解决方案：确保首次交互（如播放按钮点击）中调用 video.play()，之后再允许进度条操作；对非静音视频，务必加 muted 属性或服务端提供带音轨的 muted fallback

进度条看似简单，真正难的是跨设备行为收敛——尤其是 iOS 对“用户意图”的判定逻辑藏得很深，很多问题只在真机上复现。别依赖 console.log 看 currentTime，要用 timeupdate + seeked 双事件交叉验证实际状态。