seek是“找+定”两步异步过程：seeking为查找中，seeked才表示定位完成；需等待loadedmetadata和readyState≥2后操作currentTime，并在seeked事件中同步UI。
HTML5 媒体播放的进度控制核心在于对 currentTime 的安全读写，而 seek 操作不是“瞬间跳转”，而是一套有明确状态边界、需配合事件协同处理的异步过程。
seek 是什么？不是点击就到，而是“找+定”两步走
seek 指用户或脚本主动将播放位置跳转到指定时间点的行为，比如拖动进度条、点击快进按钮、输入时间码等。它在技术上分为两个阶段：
-
seeking：浏览器开始查找目标时间点，但尚未定位成功；此时
video.currentTime还是旧值，画面未更新，video.seeking为true -
seeked：定位完成，缓冲至少一帧，
currentTime已准确更新，video.seeking变回false
二者不是可选补充，而是必须区分使用的信号——seeking 是“正在找”，seeked 才是“已经到”。误把 seeking 当作跳转完成，会导致 UI 同步错位、日志记录偏差甚至逻辑中断。
设置 currentTime 的前提条件：元数据与就绪状态
直接赋值 video.currentTime = x 并不总有效，它依赖底层资源是否就绪：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
立即学习“前端免费学习笔记（深入）”；
- 必须等待
loadedmetadata事件，否则duration为NaN，无法计算相对位置 - 推荐检查
video.readyState >= 2（表示已有足够数据支持定位），避免在加载未完成时强行 seek - 移动端尤其敏感：未触发过用户手势（如点击播放）、或
muted未设，play()和currentTime都可能静默失败
拖动进度条的可靠实现：input + 节流 + seeked 同步
用 <input type="range"> 控制进度时，关键不在“怎么绑”，而在“何时执行”：
- 监听
input事件（非change），响应拖拽过程中的实时位置 - 对频繁触发做节流（如 300ms 内只取最后一次目标值），防止堆积未完成 seek
- 赋值
currentTime后，**不立刻读值或更新 UI**，而是等seeked触发后再同步进度条、恢复播放或上报行为 - 可在
seeking时临时禁用拖动监听，避免用户持续拖拽引发冲突
常见失效场景与应对要点
很多“跳不动”“卡住”“UI 不同步”问题，根源不在代码写错，而在时机与状态判断缺失：
- 在
timeupdate里无条件改currentTime→ 易引发循环触发，导致报错或卡死；应加标志位或改用seeked后处理 - 移动端 iOS Safari 对未播放过的视频限制极严 → 确保首次
play()由用户点击触发，且muted存在 - seek 失败（如跳到无关键帧位置）不会触发
seeked，但也不会报错 → 可监听error或检测seeking === true超时（如 3 秒）后降级处理 - 服务端未支持 HTTP Range 或 GOP 过大 → 导致 seek 加载慢、解码压力高；需配合编码优化与服务端配置
