track标签在倍速播放下字幕不同步，因其仅依赖video.currentTime绝对值而不感知playbackRate变化；需手动解析WebVTT并结合timeupdate事件实时匹配cue。
track 标签在倍速播放下字幕不同步，不是浏览器“没对齐”，而是它压根不感知倍速变化——时间戳仍按原始秒数比对 video.currentTime，而倍速改变了实际推进节奏，导致 cue 显示时机错位。必须手动补偿。
为什么 track 在倍速下会失效
浏览器原生 track 渲染逻辑只监听 video.currentTime 的绝对值，不做倍速换算。比如一个 cue 时间是 00:01:02.000 --> 00:01:04.000，正常速度下 2 秒播完；设为 2× 后，这段内容实际只用 1 秒播完，但 track 还是等 currentTime 走到 62 秒才显示、走到 64 秒才隐藏——结果就是字幕晚出现、早消失。
- 所有现代浏览器（Chrome/Firefox/Safari）都存在该行为，非 bug，是设计如此
-
textTracks的oncuechange事件触发时机也受此影响，无法靠它做可靠同步 - 即使 WebVTT 时间戳精确到毫秒，也无法绕过这个底层逻辑
用 JavaScript 手动接管字幕渲染（推荐）
放弃依赖原生 track 的自动渲染，改用 kind="metadata" 加载 WebVTT 数据，再结合 timeupdate 事件 + 倍速系数实时计算应显示的 cue。
- 先用
fetch()读取 .vtt 文件，用WebVTT.Parser或正则解析成 {start, end, text} 数组 - 监听
video.addEventListener('timeupdate', () => {...})，每次取video.currentTime - 计算当前应匹配的时间点：
const t = video.currentTime;，无需除以playbackRate——因为currentTime本身就是已受倍速影响的播放时间轴 - 遍历 cue 列表，用
t >= cue.start && t 判断是否激活，并动态更新 DOM 字幕容器内容 - 加 0.05 秒容差避免抖动：
t >= cue.start - 0.05 && t
iPad / iOS Safari 的额外陷阱
iPad 上问题更明显，不仅因倍速，还叠加了其对 WebVTT 时间戳的强制归一化：若你手动渲染时仍用原始 VTT 的 start/end 值（比如含两位小数 00:01:02.30），Safari 会把它转成整毫秒 00:01:02.300 再比对，造成微偏差累积。
从零开始创建惊艳、动画丰富且自包含的 HTML 演示文稿，或通过转换 PowerPoint 文件生成。当用户希望制作幻灯片、构建演示文稿、打造路演资料（pitch deck）、将 PPT/PPTX 转换为网页格式，或增强现有 HTML 演示文稿时，应使用此能力。该能力帮助用户通过视觉预览而非抽象选项来发掘自身审美偏好。
- 解析 VTT 时，统一将时间戳转为浮点秒并保留三位小数精度：
parseFloat('00:01:02.3') → 62.300 - 不要用
Date.parse()或字符串截取，易丢精度；用hh * 3600 + mm * 60 + ss + ms / 1000手动算 - 若字幕来自 HLS 流，注意其 PTS 可能比视频主时间轴偏移几十毫秒，需在解析后整体加/减固定 offset
- 避免在
timeupdate中直接操作 DOM 多次；缓存上一帧激活的 cue 索引，仅当切换时才更新
别碰 playbackRate 和 track 的组合幻想
有人试过在改 playbackRate 后，手动调 textTrack.mode = 'disabled' 再切回 'showing'，指望重触发同步——无效。iOS Safari 下甚至会清空 active cue 列表，导致字幕闪退；Chrome 则完全无反应。
- 原生
track的渲染和激活逻辑是黑盒，不可干预、不可重同步 - 任何试图“欺骗”浏览器让它重新对齐的操作，都会在跨设备、跨版本时失效
- 真正可控的只有你自己写的渲染逻辑：输入是当前
currentTime，输出是当前该显示哪段文本
真实场景里，最易被忽略的是「倍速变更瞬间的 cue 状态残留」：用户从 1× 切到 2× 时，上一秒还在显示的字幕可能还没到它的 end 时间，但下一秒 currentTime 已跳过，导致字幕卡住不消失。这需要你在 playbackRate 改变时，强制清空当前渲染内容，并立即用新时间重判一次。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
