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
currentTime，要用 timeupdate + seeked 双事件交叉验证实际状态。 
