html5媒体同步依靠统一时间基准、主动读取校正与分层协作实现毫秒级对齐；以主媒体currenttime为唯一可信时间源，结合requestanimationframe驱动实时校准，辅以web worker解耦计算、web audio api提升精度及底层pts/dts控制确保跨轨道同步。
HTML5 媒体同步不是靠“同时播放”实现的，而是靠统一时间基准、主动读取与校正、分层协作来维持多元素间毫秒级对齐。关键不在触发动作，而在持续感知和响应时间偏差。
以主媒体 currentTime 为唯一时间源
所有同步逻辑必须锚定在一个可信、稳定的时间点上。视频或主音频元素的 currentTime 是浏览器公开暴露的最直接、最一致的播放进度指标，比定时器（setInterval）、事件频率（timeupdate）或帧循环（requestAnimationFrame）更可靠。
- 避免用多个媒体元素各自调用 play() 后“期望它们同步”——加载延迟、解码差异、缓冲状态不同，必然导致初始偏移
- 动画、字幕、音效、标注等辅助元素，都应每帧主动读取主媒体的 currentTime，再计算自身应处状态，而非维护独立计时器
- 变速播放（playbackRate ≠ 1）时，所有依赖时间的逻辑必须乘以该系数，例如：视觉动画时间 = mainVideo.currentTime × mainVideo.playbackRate
用 requestAnimationFrame 主动驱动校准
timeupdate 事件不可靠：触发不规律、有延迟（常达 200ms+），且不保证与屏幕刷新同步。真正高精度同步需结合 requestAnimationFrame —— 它每帧执行，与渲染节奏一致，且能及时读取最新 currentTime。
- 在 rAF 回调中读取主媒体 currentTime，并批量更新字幕显示、动画位置、光标坐标等
- seek 操作后必须监听 seeked 事件，立即重置所有从属元素状态，否则动画会延续旧轨迹造成脱节
- 若需帧级精度（如音乐可视化），升级到 Web Audio API，用 audioContext.currentTime 替代 media.currentTime，它精度更高、抖动更小
Worker 分离耗时计算，保障主线程响应性
字幕时间戳动态校准、多轨道冲突排布、帧级丢帧补偿等逻辑计算量大，若放在主线程会阻塞渲染和交互。Web Worker 是理想解耦方案。
- Worker 接收主线程传入的 currentTime、playbackRate、droppedFrames、手动偏移等轻量状态，输出校准后字幕 cue 列表及渲染建议
- Worker 不操作 DOM，只做“大脑”：滑动窗口估算全局偏移、按 PTS 缩放时间戳、预测下一帧实际呈现时刻
- 主线程仅负责响应式渲染——根据 Worker 返回的 {start, end, text, render} 数据，高效更新 DOM 或 Canvas
跨媒体轨道对齐依赖底层时间戳控制
当涉及音视频分离加载（如 MSE 场景）或多音轨混音，仅靠 currentTime 同步已不够。此时必须干预媒体分片本身的时间基准。
- 使用 MediaSource 时，音视频分片必须是 fMP4 格式，且 moof box 中 PTS/DTS 可编辑；音频延迟通过整体偏移其 PTS 实现，而非调整 video.currentTime
- 多音轨同步时，选一人声或节奏轨为主轨，其余从轨初始化阶段做“冷启动延迟测量”，后续同步时应用 offset 补偿（如 MP3 额外减去 ID3 解析耗时）
- WebSocket 协同场景下，帧对齐需服务端提供统一帧总线与参考时钟，客户端用 requestVideoFrameCallback 获取 expectedDisplayTime 作为本地帧锚点，软对齐渲染
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
