currentTime不可靠，因它返回逻辑时间而非真实渲染帧时间；应改用requestVideoFrameCallback的expectedDisplayTime做帧锚点，并配合AudioContext.currentTime实现跨平台音视频高精度同步。
不同系统（尤其是 macOS/iOS 与 Windows/Android）下 video.currentTime 和 audio.currentTime 的时间精度、更新频率、起始偏移不一致，直接用它做帧对齐、进度同步或标注锚点，必然错位。根本原因不是“浏览器 bug”，而是底层媒体引擎对时钟源、解码缓冲、VSync 渲染节奏的调度差异——你得绕过 currentTime，改用更底层、更稳定的锚点。
为什么 currentTime 在不同系统上不可靠
它返回的是“播放器逻辑时间”，不是“真实渲染帧时间”：
- macOS Safari：常缓存前几帧，
currentTime滞后实际画面 2–3 帧（≈60ms），且timeupdate事件触发稀疏（每 200–500ms 一次） - iOS Safari：受 power management 影响，播放暂停再恢复时
currentTime可能跳变 ±100ms；playbackRate变化后需手动重置计时逻辑 - Windows Chrome：
currentTime相对稳定，但遇到丢帧或硬件加速切换时，会突然“卡住”不动 1–2 秒再追平 - Android WebView：部分厂商定制内核（如华为、小米）会截断小数位，只保留毫秒整数，导致连续拖动时跳帧
用 requestVideoFrameCallback 替代 currentTime 做帧锚点
这是目前唯一跨平台、高精度、与真实渲染帧强绑定的时间源。Chrome 110+、Edge 110+、Safari 17.4+ 已支持，iOS 17.4+ 也已落地。
- 它回调中的
metadata.expectedDisplayTime是基于performance.timeOrigin的绝对时间戳（单位：毫秒），误差 - 该时间点对应“这一帧被提交给 GPU 渲染的预期时刻”，比
currentTime更接近用户视觉感知 - 必须在
loadeddata或canplay后首次调用，否则可能漏掉首帧
示例：
立即学习“前端免费学习笔记（深入）”；
let frameAnchor = 0;
video.addEventListener('loadeddata', () => {
video.requestVideoFrameCallback((now, metadata) => {
frameAnchor = metadata.expectedDisplayTime;
// 后续所有标注、同步、计算都基于 frameAnchor
});
});
音频时间轴对齐要搭配 AudioContext.currentTime
纯 audio.currentTime 同样不准。正确做法是把音频解码进 AudioBuffer，用同一个 AudioContext 实例驱动所有音源，并以 context.currentTime 为统一时间轴启动：
-
context.currentTime是单调递增的高精度浮点数（单位：秒），不受音频解码延迟或缓冲影响 - 所有
bufferSource.start(context.currentTime)调用，才能真正实现多轨毫秒级同步 - 注意：iOS Safari 中
AudioContext必须由用户手势（如 click/touchend）触发才能进入运行态，否则currentTime停滞在 0
跨系统兜底策略：不要只依赖一个时间源
生产环境建议组合使用三类时间信号，按优先级 fallback：
- 首选：
requestVideoFrameCallback的expectedDisplayTime（视频主导场景） - 次选：
AudioContext.currentTime+audio.getOutputTimestamp()（仅 Chromium，返回音频输出硬件时间戳） - 保底：
performance.now()+ 首次timeupdate的差值校准（仅用于 UI 进度条，不用于帧敏感操作）
关键细节：iOS 上 requestVideoFrameCallback 在 background tab 中会暂停回调，若你的应用需后台持续对齐（如录音监听），必须监听 visibilitychange 并主动重建帧回调链。这点容易被忽略，一上线就发现锁屏后时间漂移。
