HTML5视频字幕同步需帧级精确呈现且不阻塞主线程：浏览器原生<track>仅粗粒度对齐，Web Worker承担动态偏移估算、播放速率补偿、帧级对齐预测和多轨道消解等高精度计算，主线程负责响应式渲染与Canvas逐帧控制，通信采用轻量结构化消息及Transferable对象优化性能。
HTML5 视频字幕同步不是简单把文字贴到时间点上，而是要让文字在正确帧、正确时刻、正确位置稳定呈现，同时不拖慢播放体验。核心矛盾在于：时间精度要求高，但主线程又容易被渲染、脚本、用户交互阻塞。因此逻辑设计必须分层，性能优化必须前置。
浏览器原生同步机制是基础，但不可全信
使用 <track> 标签加载 WebVTT 是最简路径，浏览器内置解析器会自动匹配 currentTime 与字幕时间戳，并触发 cuechange 事件。但这套机制有隐性限制：
- 它只做“粗粒度对齐”——每 200ms 左右检查一次当前时间，不保证帧级精确（尤其在丢帧或变速播放时）
- 无法响应手动校正（如用户按 ←/→ 微调偏移）、播放速率突变或网络延迟导致的累积误差
- 样式和布局完全交由 CSS 控制，但 DOM 渲染本身会引入额外延迟，不适合高频更新场景（如弹幕式字幕）
Web Worker 承担高精度校准计算
真正需要实时响应的逻辑（如动态偏移估算、帧率补偿、多轨道避让）应剥离至 Web Worker：
anything-to-html
下载
将调研报告、方案对比、数据分析、需求梳理、会议纪要、设计说明、代码评审、学习笔记等任务产物输出为可在浏览器直接打开的单文件 HTML，替代 Markdown 作为最终交付物。Markdown 在信息密度、视觉清晰度和可分享性上已跟不上 AI 产物的丰富度，HTML 能同时承载排版、表格、SVG 等。
- Worker 接收主线程传来的 currentTime、playbackRate、droppedFrames 和历史校正样本，输出经修正的起止时间与渲染建议
- 例如：检测到连续 3 次用户向右微调共 +120ms，则滑动窗口加权更新全局偏移量 Δt = +40ms，并对后续所有字幕时间戳统一减去该值
- Worker 不操作 DOM，只发结构化消息（如 { type: 'SYNC_HINT', cues: [...] }），避免跨线程锁和序列化开销
Canvas 渲染适合强时效性字幕场景
当字幕需逐帧控制（如歌词滚动、AR 字幕、低延迟直播字幕），用 Canvas 替代 HTML+CSS 更可控：
立即学习“前端免费学习笔记（深入）”；
- 监听 video.timeupdate 获取时间，但实际绘制由 requestAnimationFrame 驱动，确保与屏幕刷新率一致
- 每个字幕对象维护自身生命周期（startFrame、endFrame、x/y 坐标），每帧只绘制处于活跃区间的条目
- 可预设垂直轨道池（如 5 行），新字幕按空闲轨道分配，避免重叠；文字宽度用 ctx.measureText() 动态计算，适配不同字号与缩放
通信与数据传输必须轻量且可转移
主线程与 Worker、视频与字幕系统之间的数据交换，是性能瓶颈常发区：
- 字幕原始数据（尤其是长视频的数千条 cue）用 postMessage(cues, [cues.buffer]) 传输，利用 Transferable 对象避免拷贝
- timeupdate 频繁触发，但只需每 100ms 向 Worker 同步一次状态（currentTime、playbackRate 等），用节流而非防抖，防止跳过关键帧
- 避免在主线程反复解析 VTT 字符串——应在加载阶段一次性解析为数组对象，缓存后直接传递给 Worker
