HTML字幕时间轴校对需协同WebVTT文件、track加载时机与浏览器解析行为；毫秒级对齐关键在于加载后主动监听video.currentTime并手动补偿，而非依赖timeupdate事件或肉眼调试。
HTML 字幕时间轴校对不是靠“多试几次”或“肉眼调”，而是靠 WebVTT 文件内容、track 加载时机、浏览器解析行为三者协同；毫秒级对齐的关键不在字幕文件本身，而在它被加载后如何与 video.currentTime 实时匹配——这需要主动监听、手动补偿、避开浏览器默认的粗粒度同步机制。
WebVTT 时间戳写法必须用小数点，不能用逗号
WebVTT 规范要求时间格式为 HH:MM:SS.mmm（毫秒三位），且小数点是唯一合法分隔符。写成 00:01:23,456 会被部分浏览器静默忽略后三位，实际按秒级对齐。
- 正确：
00:01:23.456→ 精确到毫秒 - 错误：
00:01:23,456→ Chrome/Firefox 可能截断为00:01:23.000 - 更隐蔽的错：
00:01:23.45（只两位）→ 浏览器补零还是截断不统一，iOS Safari 尤其不稳定
不要依赖 timeupdate 事件触发字幕渲染
timeupdate 触发不可控：延迟常达 100–300ms，且在低帧率或后台标签页中会大幅降频。字幕“卡顿”“跳行”“晚出半秒”，八成源于此。
- 替代方案：用
requestAnimationFrame每帧读取video.currentTime，再查 WebVTT cue 列表中startTime ≤ currentTime 的项 - 必须预解析 WebVTT：把
.vtt内容转成 JS 数组，每个元素含{start, end, text}，避免每次查都 parse 字符串 - 注意：cue 的
end是开区间，currentTime === end时该 cue 已过期，需立即清空
手动补偿播放速率（playbackRate）和 seek 偏移
当视频变速播放（如 video.playbackRate = 1.5）或用户拖拽（seeking）后，WebVTT 时间戳仍按原始速度计算，但 currentTime 已缩放或跳变——此时若不重算，字幕必然脱节。
- 每次
video.playbackRate改变后，需重新遍历 cue 列表，把所有start/end乘以新速率（仅用于比对，不改原始文件） - 监听
seeked事件后，立刻执行一次 cue 匹配，防止因缓存旧状态导致字幕残留 - 若服务端提供 PTS/DTS 对齐信息，优先用它替代
currentTime做主时间源（需 Web Audio API 或 MediaSource Extensions 支持）
移动端 iOS Safari 的隐藏陷阱：字幕渲染延迟固定 16ms
iOS Safari 对 track 的渲染有硬性调度延迟，即使 JS 算出正确 cue 并更新 DOM，视觉上仍滞后一帧（≈16ms）。这不是 bug，是 WebKit 的合成策略。
- 对策：提前 16ms 触发显示（即当
currentTime ≥ cue.start - 0.016时就设display: block） - 但不能早太多，否则在快速跳转时会出现“字幕先于声音出现”的诡异现象
- 该补偿值需 UA 检测：仅对
WebKit+iOS生效，其他平台保持 0 补偿
真正难的不是写出毫秒时间戳，而是让浏览器在每一帧都信任你算出的那个 currentTime 值——它可能被缓冲、被丢帧、被后台节流、被跨域限制悄悄篡改。校对永远是个持续过程，不是保存文件那一刻就结束了。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
