requestvideoframecallback比timeupdate更准，因其回调发生在视频帧提交至合成器前的渲染流水线早期，直接绑定真实帧呈现时刻，并提供精确mediatime时间戳；而timeupdate仅按浏览器内部节流频率（约200ms）触发，与实际帧解码和渲染完全脱钩。
requestVideoFrameCallback 为什么比 timeupdate 更准
因为 timeupdate 事件由浏览器按内部调度频率（通常 ~200ms）触发，与视频解码帧实际呈现时刻无关；而 requestVideoFrameCallback 是在每一帧真正被提交到屏幕前的**渲染流水线早期**回调，能拿到精确的 mediaTime（即该帧在媒体时间轴上的真实播放时间戳），误差通常
常见错误是直接监听 timeupdate 并用 video.currentTime 做弹幕定位——这会导致弹幕漂移、卡顿、甚至“倒播”（因 currentTime 可能回退或跳变）。
- 必须确保视频使用
playsinline和webkit-playsinline属性（iOS Safari 必需） - 不能在未加载元数据（
loadedmetadata）前调用requestVideoFrameCallback，否则抛InvalidStateError - 该 API 当前仅 Chromium 114+、Safari 17.4+、Firefox 125+ 支持；旧版本需降级 fallback 到
timeupdate+performance.now()插值估算
如何用 requestVideoFrameCallback 获取稳定 mediaTime
回调函数接收的 callbackId 和 frameInfo 参数中，frameInfo.mediaTime 是关键——它代表当前帧在 HTMLMediaElement 时间轴上的绝对时间（单位：秒，高精度浮点数），且不受 playbackRate 变化、seek 跳转抖动影响。
注意：这个值不是“当前已播放时长”，而是“该帧本应显示的时间点”。例如视频从第 5 秒开始播放，第一帧的 mediaTime 就是 5.0，而不是 0.0。
- 每次回调都应立即调用下一次
requestVideoFrameCallback，否则会中断监听（它是一次性注册） - 避免在回调里做重计算或 DOM 批量操作，否则可能错过下一帧；弹幕渲染建议用
requestAnimationFrame节流合并 - 若视频暂停，回调会停止触发；恢复播放后首次回调的
mediaTime可能跳变，需与上一帧做差值判断是否为 seek
let lastMediaTime = 0;
function onFrame(callbackId, frameInfo) {
const { mediaTime } = frameInfo;
// 防止 seek 后首帧 mediaTime 突变干扰逻辑
if (Math.abs(mediaTime - lastMediaTime) > 0.5 && !video.paused) {
// 触发 seek 检测，可清空/重排弹幕缓冲区
}
lastMediaTime = mediaTime;
renderBarragesAtTime(mediaTime);
video.requestVideoFrameCallback(onFrame);
}
video.requestVideoFrameCallback(onFrame);
弹幕时间轴对齐的关键细节
弹幕数据里的时间戳（如 danmaku.time）必须和 frameInfo.mediaTime 使用同一时间基准。如果弹幕来自服务端，且服务端以 video.duration * progress 计算时间，那它天然对齐；但如果服务端用录制设备本地时钟打的时间戳，则必须和服务端协商统一用「媒体时间轴」而非「挂钟时间」。
另一个易错点：mediaTime 是单调递增但不严格等间隔的（尤其在低帧率或丢帧场景）。弹幕渲染不能假设“每 16ms 一帧”，而应基于当前 mediaTime 查找所有 danmaku.time ≤ mediaTime 的弹幕。
- 建议预构建弹幕时间索引（如用
Array.sort()按 time 排序，再用二分查找快速定位窗口） - 不要用
setTimeout或setInterval驱动弹幕入场——它们与媒体时钟完全脱节 - 当
playbackRate !== 1时，mediaTime仍正确反映播放位置，无需额外换算；但弹幕动画时长需按 rate 缩放（如 rate=2 时，原 2s 动画应缩为 1s）
兼容性 fallback 怎么写才不翻车
没有 requestVideoFrameCallback 时，唯一靠谱的 fallback 是结合 timeupdate + performance.now() 做线性插值，并用 video.getVideoPlaybackQuality() 监控丢帧情况动态调整策略。
别信“用 requestAnimationFrame + currentTime”这种方案——currentTime 在低性能设备上可能长时间卡住不变，导致弹幕集体停滞。
- fallback 模式下，每收到一个
timeupdate，记录{ time: video.currentTime, now: performance.now() }，构建至少两个点的映射表 - 后续用
performance.now()实时查表插值得到更平滑的估计currentTime - 一旦检测到
getVideoPlaybackQuality().droppedVideoFrames > 0，立刻暂停新弹幕入队，直到连续 3 帧无丢帧再恢复
真正在意同步精度的业务，应该把 fallback 当作临时兜底，而不是长期方案。iOS 17.4 之前无法绕过 WebKit 的限制，只能接受 100ms 级误差——这点必须提前和产品对齐。
